Convention de dénomination des artefacts

Question

Nous faisons un gros projet sur OSGi et ajoutons quelques modules communs.Il y a une discussion sur le nom de l'artefact.

Ainsi, une possibilité lors du nom du module est par exemple :

cmns-definitions (pour définitions communes), un autre est cmns-definition, encore un autre est cmns-def.Cela a également un effet sur le nom du package.Maintenant c'estxx.xxx.xxx.xxx.xxx.commons.definitions, si vous passez à cmns-def ce serait xx.xxx.xxx.xxx.xxx.commons.def.

À l'intérieur de ce package se trouveront des classes telles que des énumérations et d'autres définitions à utiliser dans tout le système.

Personnellement, je penche pour cmns-definitions puisqu'il n'y a pas qu'une seule définition à l'intérieur du package.D'autres personnes soulignent que java.util n'y a pas qu'un seul utilitaire par exemple.Toujours, java.util est un abréviation pour moi.Cela peut signifier utilitaire Java ou utilitaires Java.La même chose arrive avec commons-lang.

Comment nommeriez-vous le paquet ?Pourquoi choisiriez-vous ce nom ?

1. cmns-definitions
2. cmns-definition
3. cmns-def

Question bonus:Comment nommer quelque chose comme cmns-exceptions?C'est comme ça que je l'appelle.Voudriez-vous le nommer cmns-xcpt?

MODIFIER:

J'expose mes propres réflexions à ce sujet dans l'espoir d'être confirmées ou contredites.Si vous le pouvez, faites-le.

D'après ce que je pense, la raison pour laquelle vous nommez quelque chose est de faciliter la compréhension de ce qu'il contient.Ou, selon Peter Kriens, de faciliter la mémorisation et de pouvoir automatiser les processus via des modèles.Les deux sont des arguments valables.

Mon raisonnement est le suivant en termes de modèle :

1) Lorsqu'une justification apparaît et qu'elle est bien connue dans l'industrie, suivez-la sur votre nom.
Par exemple:"Caractéristiques" en est un exemple.Nous avons un module appelé cmns-features.Cela signifie-t-il que nous avons de nombreuses fonctionnalités sur ce module ?Non.Cela signifie "le module qui implémente le fichier "features" d'Apache karaf".
« communs » est une justification du « commun » bien acceptée dans l'industrie.Cela ne veut pas dire « beaucoup de choses communes ».Cela signifie « Code commun ».

Si je vois extr-commons comme nom de module, je sais qu'il contient du code commun pour extr (dans ce cas, l'extraction), par exemple.

2) Lorsqu'un certain nombre de classes à l'intérieur du module coopèrent pour donner une signification distincte "une et une seule" à l'ensemble, utilisez la forme singulière pour le nommer.

La majorité des modules sont inclus ici.Si je nomme quelque chose cmns-persistence-jpa, je veux dire que toutes les classes à l'intérieur coopèrent ensemble pour fournir l'implémentation jpa de cmns-persistence-api.Je ne m'attends pas à 2 implémentations à l'intérieur, mais en fait à une myriade de classes qui, ensemble, forment une seule implémentation.C'est clair pour moi.Non?

3) Lorsqu'un regroupement de classes se fait dans le seul but de rassembler des classes par affinité, mais que les classes ne coopèrent pas entre elles en vain, utilisez le pluriel.

Voici le cas par exemple des définitions cmns (énumérations utilisées par l'ensemble du système).

Alternativement, l'utilisation d'une abréviation évite le problème, par ex.cmns-def qui peut également être « interprété étendu » par un lecteur humain aux définitions cmns.Beaucoup de gens utilisent également "xxxx-util" qui signifie xxxx-utilitaires.

Une troisième option peut encore être utilisée pour regrouper les choses, en utilisant un nom qui signifie lui-même une pluralisation.Le mot "api" me vient à l'esprit, mais n'importe quel mot qui met quelque chose au pluriel ferait l'affaire, comme "pack".

Ces cas (3) sont pris en charge par des modules bien connus comme commons-collections (en utilisant le pluriel) ou commons-dbcp (en utilisant une abréviation) ou commons-lang (encore une fois une abréviation) et tout ce qui utilise l'API pour regrouper les classes par affinité.

Depuis Apache :
commons-collections -> de nombreuses structures de données puissantes qui accélèrent le développement des applications Java les plus importantes
commons-lang -> hôte d'utilitaires d'assistance pour l'API java.lang
commons-dbcp -> package de plusieurs pools de connexions à la base de données

Answer 1

'c'est juste un nom...'

J'ai découvert au cours de ma longue carrière que ces simples noms peuvent faire une énorme différence en termes de productivité.Je ne pense pas que cela fasse une différence si vous utilisez définitions, définition, ou déf tant que vous êtes cohérent et que vous utilisez des modèles dans le nom qui sont faciles à retenir et peuvent être utilisés pour automatiser les processus.Une construction basée sur un schéma de dénomination cohérent est infiniment plus facile à utiliser qu'une construction avec des noms « d'affichage humain agréable » qui sont ad hoc et n'ont aucun modèle perceptible.

Si vous utilisez des modèles, les noms ont tendance à devenir plus courts.Désormais, les personnes travaillant avec ces noms passaient généralement beaucoup de temps avec eux.Leur lisibilité n’est donc pas aussi importante que leur valeur mnémonique.Il s’avère que les abréviations de 3 ou 4 caractères sont étonnamment puissantes.L'une des raisons pour lesquelles ils fonctionnent bien est qu'il n'y a qu'une seule abréviation possible alors que si vous y allez plus longtemps, il y a de nombreux candidats.

Quoi qu’il en soit, l’aspect le plus important est la cohérence globale.Bonne chance.

Answer 2

definitions (ou def ou definition) est un mauvais nom car il n'a aucune sémantique pour le lecteur.Vous êtes dans un monde orienté objet (je suppose) – essayez de suivre ses conventions et ses principes.Les modules de Maven doivent être nommés d'après la plus grande "abstraction" qu'ils contiennent.La « définition » est une forme et non un sens.

Votre question est similaire à :"Quel nom de classe est le meilleur FileUtilities ou FileUtils".Répondre:aucun.

Answer 3

Fondamentalement, ce que vous faites avec les définitions et les exceptions est de fournir une sorte d'API pour vos autres modules.Je propose donc de combiner des définitions, des exceptions et d'y ajouter des interfaces.Il est alors logique de tout appeler cmns-api.Je préfère normalement les noms au singulier car ils sont plus courts mais vous êtes libre de décider car ce n'est qu'un nom.