web-dev-qa-db-fra.com

Meilleure façon de nommer les classes et les packages dans Java

Outre les conventions de code pour utiliser camelCase, PascalCase, etc., existe-t-il des conventions pour nommer les packages et les classes en Java?

Par exemple, j'ai un projet mvc et le package principal est com.myproject. Dans ce package, j'ai:

  1. com.myproject.model
  2. com.myproject.view
  3. com.myproject.controller.

Existe-t-il une convention ou une meilleure pratique pour donner un nom à la classe dans ces 3 packages? Comme pour le package 1, évitez le modèle dans le nom de classe, ou quelque chose comme ça? Et si je veux utiliser le même nom de classe comme User, quoi de mieux: utiliser UserModel, UserView, UserController, ou donner le même nom aux 3 classes? Existe-t-il une sorte de meilleure pratique ou de convention de dénomination pour ce faire?

javanamingclass-designpackage-managers
6
Liz Lamperouge

Réponse courte: Nommer deux classes identiques dans le même projet/bibliothèque/contexte n'est pas recommandé.

Mis à part l'inconvénient évident, il y a un point plus profond pourquoi ce n'est pas une bonne idée et le nom de votre package n'est pas non plus proposé. En tant que développeurs, nous sommes responsables de la modélisation des problèmes commerciaux , et notre vocabulaire de dénomination devrait refléter ce fait. C'est en quelque sorte le point de la conception pilotée par domaine.

Mettre la technologie au-dessus de la fonction réelle pourrait être logique pour nous, car nous sommes plus intéressés par la technologie, les modèles, l'architecture et des choses comme ça, mais rend notre modèle moins expressif, moins maintenable.

Mon point est le suivant: Les noms de package et les noms de classe doivent refléter les concepts métier . Il ne doit pas y avoir de packages model, view, controller, il ne doit pas y avoir de classes UserModel, UserController, etc.

Modélisez le problème, pas la technologie! Trouvez des abstractions appropriées directement à partir des exigences de l'entreprise et masquez les détails de l'implémentation, comme le fait que vous utilisez MVC.

13
Robert Bräutigam

En général, donner le même nom à plusieurs classes dans le même projet (pas package, project) est une mauvaise pratique. Entre autres mauvaises choses qui peuvent se produire, si ces choses doivent se référer les unes aux autres, cela devient ambigu, que, par exemple, "Utilisateur" vous essayez d'instancier lorsque vous créez un nouvel Utilisateur.

Dans MVC, la façon dont je l'ai généralement vu est que votre package est nommé com.MYNAME.PROJECTNAME, puis ajoutez .MODULENAME pour chaque module (dans votre cas, "model", "view", "controller", etc.)

En ce qui concerne les classes, le nom de votre classe doit indiquer ce qu'est la classe. S'il s'agit d'un contrôleur pour votre objet utilisateur, il doit s'appeler UserController. Cela est vrai même si le package est le module "contrôleur"; lorsque vous regardez du code dans un IDE, il est facile de se tromper ou d'oublier quel package vous regardez pour un fichier donné.

1
Ertai87

Les conventions de dénomination sont quasiment laissées au développeur ou à l'équipe la plupart du temps. Pour moi personnellement, je me suis presque toujours appuyé sur les informations publiées via Oracle lorsque je travaille en Java.

http://www.Oracle.com/technetwork/Java/codeconventions-135099.html

Plus directement lié à votre question, si vous vouliez avoir une classe appelée "Personne" dans les trois packages, cela serait admissible. Lorsque vous souhaitez inclure ces packages quelque part et utiliser réellement les classes qui s'y trouvent, c'est là que vous verrez que cela peut ou non être une bonne idée.

En regardant les noms de vos packages, par exemple, "com.myproject.model", pourquoi auriez-vous une classe appelée "Model" par rapport à autre chose, comme "Person" ou "Order"?

Peut-être que je comprends mal la question, mais il est plus logique pour moi qu'elle soit utilisée de cette manière, comme dans le pseudocode suivant:

com.myproject.model.Person x = new com.myproject.model.Person();
1
RobertMcAtee

Quel que soit le langage, mais spécifiquement en Java, vous souhaitez, plus ou moins, suivre ces directives:

  1. Classes nommées d'après des noms (imprimante, contrôleur, boîte aux lettres, gestionnaire, gestionnaire), ce qui signifie quelque chose, une entité qui logique dans votre domaine problématique.
  2. Les interfaces comme adjectifs (Iterable, Serializable, Secured, Asynchronous), c'est-à-dire une capacité ou une caractéristique d'une entité mettant en œuvre ladite interface.
  3. Méthodes sous forme de verbes ou, dans certains cas, d'adverbes ou de clauses adverbiales, selon ce qui est logique pour décrire une action (exécuter, livrer, valider)
  4. Les packages en tant que regroupement de choses qui ont du sens d'être ensemble (encore une fois, cela est très fortement lié à votre domaine problématique.)

Au-delà de ces directives générales (pas des règles, mais des directives ou des suggestions), il est difficile de donner des exemples concrets sans avoir un domaine de problème concret.

Nous voulons définir un domaine problématique indépendamment du langage de programmation, un domaine qui décrit la fonctionnalité dont vous avez besoin, et les entités qui fournissent la fonctionnalité, et les interactions entre eux.

Alors et seulement alors vous avez un point de départ pour commencer à nommer les classes, les packages et les méthodes.

1
luis.espinal