Як поводитися з класами з однаковою назвою (різні пакети)

9

Я та моя команда з науково-дослідної роботи підтримуємо велику кодову базу. Ми розділили свою бізнес-логіку на кілька пакетів. деякі з яких мають класи з однаковими назвами .

Як ви здогадаєтесь, імена конфліктують, коли обидва класи посилаються на один і той же файл Java.

Наприклад:

com.myapp.model (package)
 - Device (class)
 - ...

com.myapp.data (package)
 - Device (class)
 - ...

Ми мали дискусію щодо того, яка найкраща практика для лікування цих випадків, і з'явилися наступні варіанти:

1-й варіант

Перейменування класу, додавання префікса
```
ModelDevice
DataDevice
```

2-й варіант

Використання повного пакета + назва класу, коли на них посилаються обидва
```
com.myapp.model.Device
com.myapp.data.Device
```

Що правильніше з точки зору управління кодом та масштабованості?

в даний час ми змішуємо обидва підходи і починаємо суперечити

— Йосеф Харуш
джерело

Якщо це іноді, це, мабуть, не має значення - якщо це повторювана закономірність, я б, мабуть, назвав класи точніше, щоб запобігти тому, щоб він став безладом.

— assylias

Ви не маєте поняття, наскільки я ненавиджу java.util.Dateі java.sql.Date- тим більше java.sql.Date, що це підклас java.util.Dateі так непогано вислизає з шарів даних (і не серіалізується добре на JSON).

Варіант 2.1 Завжди використовуйте повністю кваліфіковане ім'я, навіть якщо інше не посилається

— Caleth

18

Використовуйте назву пакета. Саме такий тип проблеми полягає в тому, що Java використовує конвенцію про іменування пакунків, яку вона робить. Це запобігає подібним проблемам, будь то дві команди в одній компанії або дві команди на протилежних сторонах землі.

— Брайан Оуклі
джерело

1

На даний момент у вас є один клас ModelDevice (Пристрій у пакеті моделей). Що робити, якщо у вас є інший такий ModelDevice для іншої класифікації? Проблема може все ще зберігатися, а накладні витрати також продовжуватимуть збільшуватися.

Хоча на даний момент ви можете виявити, що перейменування класів може бути корисною, але довгостроково запропонованим альтернативним рішенням є просування за допомогою префіксації назв пакета, що і є галузевим стандартом.

— itraghz
джерело

0

Просто додати один аспект, про який ще не було сказано:

Погляньте на схеми використання, тобто джерела Java, які посилаються на один або обидва класи.

IMHO у більшості випадків у вихідних файлах має посилатися лише на один із конфліктуючих класів, і з контексту повинно бути зрозуміло, чи стосуються вони моделі та світу даних. Якщо це важко з будь-якої причини, я б перейменував класи, оскільки я, як правило, не люблю назви класів з префіксом пакету у вихідному коді (це погіршує читабельність).

Якщо у вас є вихідні файли, які мають справу з обома світами, вони можуть бути об'єднаними класами з можливістю перекладу між двома різними поглядами на світ, і тут я вважаю за краще знайти назви класів з префіксованими пакетами.

Але бачення обох класів пристроїв в одному джерелі також може бути натяком на те, що джерело порушує принцип єдиної відповідальності шляхом змішування завдань із моделі та світу даних.

— Ральф Клеберхофф
джерело