Structure application (classe)

Bonjour à tous,

Prenons un exemple simple.
Un garage automobile (un grand garage :-) ) possède plein de voitures de différentes marques et modèles.
J'ai donc une classe Voiture avec ses propriétés et méthodes.
Imaginons que le garagiste veuille faire un inventaire. Il a donc besoin d'une méthode quelque part ( par exemple GetAllCars) qui donne donc la liste de toutes les voitures.
Aujourd'hui je place cette méthode dans ma classe voiture.
Est-ce que c'est une bonne pratique ou alors devrais-je par exemple créer une classe Voitures où je pkacerais cette méthode ? Ou alors procéder d'une autre manière ?

Merci d'avance.

Bonjour,

Mettre ta méthode GetAllCars() dans Voiture, n'est pas une bonne pratique, dans le sens où ça 'oblige' une voiture à connaitre toutes les autres.
Donc faire une classe Voitures qui la contiendrait reste une bonne solution.

Bonne continuation.

Ok, Merci.

Bonjour,

Citation:

---

Envoyé par Kyroon

Mettre ta méthode GetAllCars() dans Voiture, n'est pas une bonne pratique, dans le sens où ça 'oblige' une voiture à connaitre toutes les autres.
Donc faire une classe Voitures qui la contiendrait reste une bonne solution.

---

Je ne serais pas aussi catégorique. Cela dépend de ton projet. Est-ce que tu as une base de données derrière et ta classe Voiture n'est qu'une couche d'accès ? Si oui, tu peux très bien faire une méthode statique qui te retourne l'ensemble des voitures de ton garage.

Oui c'est cela, il y a une base SQL Server derrière.
Dans mon appli j'ai déjà tout un tas de méthodes statiques rassemblées pour des questions pratiques dans une classe "Global", où j'ai par exemple des vérifications de format de mail, génération de mot de passe, remplissage listview à partir d'une list, etc...
A ce moment là, cette méthode GetAllCars(), dois-je là mettre avec ces méthodes statiques ou dans ma classe voiture?

Je suis bien conscient que dans les 2 cas çà fonctionnera, mais je cherche à savoir à des fins de progression et de bonne pratique, où est-il recommandé de la mettre.

Merci pour le complément d'info. A partir de là, oui, je mettrais cette méthode statique au niveau de la classe voiture. C'est là où cela me parait le plus logique.

Ainsi, toute la logique concernant les voitures est traitée en une seule et même classe.

Ta Classe Voiture représente une seule voiture ?
N'a tu pas un objet (collection, tableau ...) qui regroupe tes voitures ?

Bonjour à tous,

Je sens que cette discussion va devenir intéressante :)
Déjà il faut que tu es conscience qu'il y a plusieurs (beaucoup ?) de façon de faire et que tu trouveras ici des réponses différentes qui ont toutes des avantages et des inconvénient.

Pour ma part, et comme ericlm128, je partirais sur une classe 'au dessus' de ta classe Voiture que l'on pourrait appeler ParcVoiture, ou GestionVoiture ou tout comme te le dis ericlm128 Voitures (moi aussi j'aime bien juste mettre un s à la fin d'une classe de ce genre :kiss: ) qui gérera toutes tes voitures, elle te permettra d'ajouter des voitures à ton parc de voitures d'en retirer, d'avoir des infos sur le nombre de voiture dans ton parc, te donner les voitures qui ont une roue crevée ...etc à toi de voir. Si tu pense que ton appli devra évoluer dans un futur proche alors je pense que c'est la bonne solution. A mes début c'est souvent une erreur que je faisais (enfin c'est ce que je pense aujourd'hui), de ne pas faire de classe de gestion au-dessus d'une classe métier, typiquement je créais une classe Personne, mais jamais de classe CarnetAdresse ou Annuaire, et finalement quand on le fait on trouve ça vachement plus simple et naturel, et en plus on respect du coup encore plus le principe d'une classe une responsabilité :plusser:

Après je ne rejèterais pas aussi vite que ça la remarque de dorinf, une méthode static qui te retourne tes Voiture dans la classe Voiture, j'ai longtemps fais ça, mais je le fais plus, car si Voiture est une classe métier (et non une classe d'accès au donnée) alors tu vas mélanger la couche métier et la couche d'accès aux données, faut arrêter d'être puriste jusqu'au bout des ongles, et peut être que ton projet n'a pas vraiment d'intérêt d'avoir une vraie séparation des couches, que c'est une petite appli qui ne va pas beaucoup bouger par la suite alors tu gagneras un peu de temps avec une simple méthode static. Le risque de cette solution c'est que ta classe Voiture va devenir énorme avec le temps si ton appli devra évoluer, et finir par mélanger des concepts.

Bon code,
J@ck.

Le S de SOLID veut dire Single responsibility principle
So... :mrgreen: