Moi et mon équipe R&D maintenons une grande base de code. Nous avons divisé notre logique métier en plusieurs packages. dont certains ont classes avec des noms identiques.
Comme vous pouvez le deviner, les noms entrent en conflit lorsque les deux classes sont référencées dans le même fichier Java.
Par exemple:
com.myapp.model (package)
- Device (class)
- ...
com.myapp.data (package)
- Device (class)
- ...
Nous avons eu un débat sur la meilleure pratique pour traiter ces cas et les options suivantes ont été proposées:
Renommer la classe, ajouter un préfixe
ModelDevice
DataDevice
Utilisation du package complet + nom de classe lorsque les deux sont référencés
com.myapp.model.Device
com.myapp.data.Device
nous mélangeons actuellement les deux approches et commençons à avoir des incohérences
Utilisez le nom du package. Ce type de problème est précisément la raison pour laquelle Java utilise la convention de dénomination de package qu'il fait. Il empêche ce genre de problèmes, qu'il s'agisse de deux équipes dans la même entreprise ou de deux équipes situées de part et d'autre de la terre. .
Vous disposez désormais d'une classe ModelDevice (Device dans le package de modèle). Et si vous avez un autre ModelDevice de ce type pour une classification différente? Le problème peut persister et les frais généraux continueront également d'augmenter.
Bien que, pour le moment, vous puissiez trouver que renommer des classes soit d'une grande aide, pour une longue période, l'alternative suggérée consiste à préfixer les noms des packages, ce qui est le standard de l'industrie.
Juste pour ajouter un aspect qui n'a pas encore été mentionné:
Jetez un œil aux modèles d'utilisation, c'est-à-dire aux sources Java qui font référence à une ou aux deux classes.
À mon humble avis, dans la majorité des cas, les fichiers source ne devraient faire référence qu'à une seule des classes en conflit et, du contexte, il devrait être clair s'ils traitent du modèle ou du monde des données. Si c'est difficile pour une raison quelconque, je renommerais les classes, car je n'aime généralement pas les noms de classe préfixés par les packages dans le code source (cela dégrade la lisibilité).
Si vous avez des fichiers sources qui traitent des deux mondes, ils pourraient être des ponts entre les classes avec la responsabilité de traduire entre deux vues différentes du monde, et ici je préférerais trouver des noms de classe avec préfixe de package.
Mais voir les deux classes de périphériques dans une seule source pourrait aussi bien être un indice que la source viole le principe de responsabilité unique en mélangeant les tâches du modèle et du monde des données.