La convention de nom de package Java est-elle défectueuse? [fermé]

Nous connaissons tous la convention du nom de package Java pour changer le nom de domaine. C'est-à-dire www.evilcorp.com, par convention, aurait choisi d'avoir leurs packages java com.evilcorp.stuff.

De plus en plus j'en ai marre de ça. En tant que programmeur commercial, je rencontre maintes et maintes fois que le nom du progiciel est complètement hors de propos en raison d'une nouvelle marque, d'une acquisition ou similaire.

Dans le monde open source, il y a moins de changements de nom, donc c'est logique. Cependant, il me semble que la durée de conservation de nombreux logiciels (commerciaux / internes) est beaucoup plus longue que celle de l'organisation qui les fabrique.

Le problème est souvent aggravé par les projets logiciels prenant la direction du service marketing pour utiliser le nom du jour qu'ils utilisent pour désigner un certain projet. Un nom qui, sans faute, changera 3 mois plus tard pour que les nouveaux vêtements de l'empereur soient frais et neufs.

Pour cette raison, j'ai principalement cessé d'utiliser le domaine inverse comme nom de package. Certes, si cela se fait à grande échelle, il y a un risque de collision de noms, mais cela est sûrement atténué soit en utilisant des noms de logiciels «uniques», en évitant les mots génériques, soit en utilisant le domaine inverse pour les projets destinés à être vendus / publiés en tant que bibliothèques. .

D'autres pensées?

Je vais citer les conseils que Microsoft donne pour les espaces de noms (packages de .NET), qui n'ont pas la convention de nom de domaine. Je pense que c'est aussi un bon conseil pour les packages Java, car je ne crois pas qu'un nom de domaine représente une identité solide et stable.

Le format général d'un nom d'espace de noms est le suivant:

<Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]

Par exemple Microsoft.WindowsMobile.DirectX,.

Effectuez le préfixe des noms d'espace de noms avec un nom de société pour empêcher les espaces de noms de différentes sociétés d'avoir le même nom et le même préfixe.

Utilisez un nom de produit stable et indépendant de la version au deuxième niveau d'un nom d'espace de noms.

N'utilisez pas les hiérarchies organisationnelles comme base pour les noms dans les hiérarchies d'espace de noms, car les noms de groupe au sein des sociétés ont tendance à être de courte durée.

Le nom de l'espace de noms est un identifiant de longue durée et immuable. À mesure que les organisations évoluent, les modifications ne doivent pas rendre le nom d'espace de noms obsolète.

Si même le nom de votre entreprise est instable, vous pouvez commencer par le nom du produit.

Vous cherchez la solution à un problème différent, à savoir comment éviter que le programmeur X et le programmeur Y ne se mettent l'un sur l'autre en mettant les fichiers dans le même package.

Le "juste inverser votre nom de domaine" résout cela d'une manière élégante, car vous êtes alors certain que si X et Y ne sont pas liés, ils ne choisiront pas le même espace de nom de package.

La convention n'est pas défectueuse. Les gens sont imparfaits, comme vous vous en êtes bien illustré.

Je peux penser à 2 avantages:

1. Il évite les collisions entre développeurs indépendants. Un domaine est unique. Deux personnes peuvent nommer deux projets différents de la même façon, mais un domaine a exactement un propriétaire.
2. Cela facilite la recherche du responsable. Si vous héritez d'une base de code, qui utilise une bibliothèque open source, il vaut mieux être dans un package qui vous aide à la trouver. À ce stade, cela n'a plus vraiment d'importance, car vous pourrez certainement le rechercher sur Google. Mais il y a 10 ans, ce n'était pas si évident.

Le nom de domaine inversé a été utilisé pour éviter les collisions de noms au cas où différentes organisations utiliseraient les mêmes noms de classe dans leurs bibliothèques. C'est une solution simple et hors cource a quelques inconvénients (par exemple, qu'en est-il des collisions de noms pour les classes dans la même organisation?).

Vous n'êtes pas obligé de l'utiliser, c'est une convention et non une règle de faire ou mourir. Par exemple, certains programmeurs Java ne respectent pas les conventions de code Java .

Mais considérez les alternatives. Comment aimeriez-vous, par exemple, deux noms de classe complets pour une LogFactory:

a50e8400_e29b_41d4_a716_446655440000.LogFactory
f47ac10b_58cc_4372_a567_0e02b2c3d479.Logfactory

ou

org.apache.commons.logging.LogFactory
com.evilcorp.logging.LogFactory

Donc, dans mes pensées, utilisez ce que vous voulez tant que cela inclut le bon sens et une considération pour les utilisateurs de votre bibliothèque.

Lorsque je démarre un nouveau projet, j'insiste toujours sur un nom interne et immuable que les responsables marketing peuvent ou non connaître, car il ne sera mentionné que dans le code source. De cette façon, je n'ai pas à me soucier des changements de nom de projet et de la pollution de l'espace de noms.

Ce scénario me convient, car le code source n'est généralement pas une partie importante du produit, c'est-à-dire que les projets sont généralement des systèmes propriétaires à source fermée. Cependant, dans les projets open source où le code source est le produit, cela pourrait ne pas être possible.