Il y a quelque temps, j'ai vu une réponse à une question concernant l'organisation fine des packages java. Par exemple, my.project.util
, my.project.factory
, my.project.service
, etc.
Je ne le trouve pas maintenant, je peux donc aussi bien poser la question.
Existe-t-il des meilleures pratiques en ce qui concerne l'organisation des packages en Java et que contiennent-ils?
Comment organisez-vous vos cours dans votre projet Java?
Par exemple, un projet sur lequel je travaille avec quelques personnes a un package appelé beans. Il a commencé par être un projet contenant des haricots simples, mais a fini par (par mauvaise expérience et manque de temps) contenir tout (presque). Je les ai nettoyés un peu, en mettant certaines classes d'usine dans un package d'usine (classes avec des méthodes statiques qui créent des beans) mais nous avons d'autres classes qui font de la logique métier et d'autres qui font un traitement simple (pas avec la logique métier) comme la récupération un message pour un code d'un fichier de propriétés.
Vos idées et commentaires sont appréciés.
la source
Réponses:
L'organisation ou la structuration d'un package est généralement une discussion animée. Voici quelques directives simples pour nommer et structurer les packages:
com.company.product.modulea
com.company.product.module.web
oucom.company.product.module.util
etc.com.company.product.model
etcom.company.product.util
, etc.Après quelques expériences et essais, vous devriez pouvoir trouver une structure avec laquelle vous êtes à l'aise. Ne soyez pas obsédé par une seule convention, soyez ouvert aux changements.
la source
J'organise les packages par fonctionnalité , pas par modèles ou rôles d'implémentation. Je pense que des packages comme:
beans
factories
collections
sont faux.
Je préfère, par exemple:
orders
store
reports
afin que je puisse masquer les détails d'implémentation grâce à la visibilité du package . L'usine de commandes doit être dans le
orders
package afin que les détails sur la création d'une commande soient masqués.la source
Réponse courte: Un package par module / fonctionnalité, éventuellement avec des sous-packages. Rassemblez des choses étroitement liées dans le même package. Évitez les dépendances circulaires entre les packages.
Réponse longue: je suis d'accord avec la plupart de cet article
la source
Je préfère la fonctionnalité avant les calques, mais je suppose que cela dépend de votre projet. Considérez vos forces:
Essayez de minimiser les dépendances des packages, en particulier entre les fonctionnalités. Extrayez les API si nécessaire.
Dans certaines organisations, les équipes travaillent sur des fonctionnalités et dans d'autres sur des couches. Cela influence l'organisation du code, l'utilise pour formaliser les API ou encourager la coopération.
Mettre tout dans un module simplifie le déploiement et la versionnage, mais la correction des bogues est plus difficile. La division des éléments permet un meilleur contrôle, une évolutivité et une disponibilité accrues.
code bien organisé est beaucoup plus simple à changer qu'une grosse boule de boue.
Plus elle est grande, plus elle doit être formalisée / standardisée.
Certains codes sont plus importants que d'autres. Les API devraient être plus stables que l'implémentation. Il doit donc être clairement séparé.
Il devrait être possible pour un étranger de savoir de quoi parle le code et où commencer la lecture en regardant l'arborescence des packages.
Exemple:
C'est juste un exemple. C'est assez formel. Par exemple, il définit 2 interfaces pour feature1 . Normalement, cela n'est pas obligatoire, mais pourrait être une bonne idée s'il est utilisé différemment par différentes personnes. Vous pouvez laisser l'API interne étendre le public.
Je n'aime pas les noms 'impl' ou 'support', mais ils aident à séparer les choses moins importantes des importantes (domaine et API). Quand il s'agit de nommer, j'aime être le plus concret possible. Si vous avez un paquet appelé 'utils' avec 20 classes, passez
StringUtils
à support / string,HttpUtil
à support / http et ainsi de suite.la source
Non, pas vraiment. Il y a beaucoup d'idées et beaucoup d'opinions, mais la vraie "meilleure pratique" est d'utiliser votre bon sens!
(Veuillez lire Pas de meilleures pratiques pour avoir une perspective sur les "meilleures pratiques" et les personnes qui les promeuvent.)
Cependant, il y a un principe qui est probablement largement accepté. La structure de votre package doit refléter la structure (informelle) du module de votre application, et vous devez viser à minimiser (ou idéalement éviter complètement) les dépendances cycliques entre les modules.
(Les dépendances cycliques entre les classes d'un package / module sont très bien, mais les cycles inter-packages ont tendance à compliquer la compréhension de l'architecture de votre application, et peuvent être un obstacle à la réutilisation du code. En particulier, si vous utilisez Maven, vous constaterez que cyclique Les dépendances inter-packages / inter-modules signifient que l'ensemble du désordre interconnecté doit être un artefact Maven.)
Je dois ajouter qu'il y a une meilleure pratique largement acceptée pour les noms de paquets. Et c'est que les noms de vos packages doivent commencer par le nom de domaine de votre organisation dans l'ordre inverse. Si vous suivez cette règle, vous réduisez la probabilité de problèmes causés par des conflits entre vos noms de classe (complets) et ceux d'autres personnes.
la source
J'ai vu certaines personnes promouvoir le «package par fonctionnalité» au lieu de «package par couche», mais j'ai utilisé pas mal d'approches au cours des années et j'ai trouvé «package par couche» beaucoup mieux que «package par fonctionnalité».
De plus, j'ai trouvé qu'une stratégie hybride: «package par module, couche puis fonctionnalité» fonctionne extrêmement bien dans la pratique car elle présente de nombreux avantages du «package par fonctionnalité»:
J'explique en détail ici: Structure et organisation du nom du package Java, mais ma structure de package standard est:
revdomain.moduleType.moduleName.layer. [layerImpl] .feature.subfeatureN.subfeatureN + 1 ...
Où:
revdomain domaine inverse de la com.mycompany
moduleType [app * | framework | util]
moduleName par exemple myAppName si le type de module est une application ou «finance» si c'est un cadre comptable
couche [modèle | ui | persistance | sécurité etc.,]
layerImpl par ex., portillon, jsp, jpa, jdo, hibernate (Remarque: non utilisé si le calque est le modèle)
fonctionnalité, par exemple, finances
sous-fonctionN p. ex., comptabilité
sous-fonctionN + 1 par exemple, dépréciation
* Parfois, «app» est omis si moduleType est une application, mais la mettre dedans rend la structure du package cohérente sur tous les types de modules.
la source
Je ne connais pas les pratiques standard pour l'organisation des packages. Je crée généralement des packages qui couvrent un spectre raisonnablement large, mais je peux faire la différence au sein d'un projet. Par exemple, un projet personnel sur lequel je travaille actuellement a un package dédié à mes contrôles d'interface utilisateur personnalisés (plein de classes sous-classes swing classes). J'ai un package dédié à ma gestion de base de données, j'ai un package pour un ensemble d'écouteurs / événements que j'ai créés, etc.
D'un autre côté, j'ai demandé à un collègue de créer un nouveau package pour presque tout ce qu'il a fait. Chaque MVC différent qu'il voulait avait son propre package, et il semblait qu'un ensemble MVC était le seul groupe de classes autorisé à être dans le même package. Je me souviens à un moment donné, il avait 5 packages différents qui avaient chacun une seule classe en eux. Je pense que sa méthode est un peu extrême (et l'équipe l'a forcé à réduire le nombre de packages alors que nous ne pouvions tout simplement pas le gérer), mais pour une application non triviale, il faudrait tout mettre dans le même package. C'est un point d'équilibre que vous et vos coéquipiers devez trouver par vous-même.
Une chose que vous pouvez faire est d'essayer de prendre du recul et de penser: si vous étiez un nouveau membre présenté au projet, ou si votre projet a été publié en open source ou en API, comment serait-il facile / difficile de trouver ce que vous voulez? Parce que pour moi, c'est ce que je veux vraiment des packages: l'organisation. Semblable à la façon dont je stocke les fichiers dans un dossier sur mon ordinateur, je m'attends à pouvoir les retrouver sans avoir à rechercher tout mon lecteur. J'espère pouvoir trouver la classe que je veux sans avoir à rechercher la liste de toutes les classes dans le package.
la source