Comment gérer les classes ayant le même nom (différents packages)

9

Moi et mon équipe R&D maintenons une grande base de code. Nous avons divisé notre logique métier en plusieurs packages. certains ont des 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:

1ère option

Renommer la classe, ajouter un préfixe
```
ModelDevice
DataDevice
```

2e option

Utilisation du package complet + nom de classe lorsque les deux sont référencés
```
com.myapp.model.Device
com.myapp.data.Device
```

Quoi de plus correct en termes de gestion de code et d'évolutivité?

nous mélangeons actuellement les deux approches et commençons à avoir des incohérences

— Jossef Harush
source

Si c'est occasionnel, cela n'a probablement pas d'importance - s'il s'agit d'un modèle récurrent, je nommerais probablement les classes plus précisément pour éviter qu'il ne devienne un gâchis.

— assylias

Vous n'avez aucune idée de ce que je déteste java.util.Dateet java.sql.Date- d'autant plus qu'il java.sql.Dates'agit d'une sous-classe de java.util.Dateet se glisse donc bien hors des couches de données (et ne se sérialise pas bien en JSON).

Option 2.1 Utilisez toujours le nom complet, même si l'autre n'est pas référencé

— Caleth

18

Utilisez le nom du package. Ce type de problème explique précisément pourquoi Java utilise la convention de dénomination des packages qu'il utilise. Cela évite ce genre de problèmes, que ce soit deux équipes dans la même entreprise ou deux équipes de part et d'autre de la terre.

— Bryan Oakley
source

1

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.

— itsraghz
source

0

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 référencent une ou les 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.

— Ralf Kleberhoff
source