За замовчуванням vs Impl при реалізації інтерфейсів на Java

Після прочитання Чи повинні назви пакетів бути одниною чи множиною? мені прийшло в голову, що я ніколи не бачив належної дискусії щодо одного з моїх вихованців: називання реалізацій інтерфейсів.

Припустимо, що у вас є інтерфейс, Orderякий повинен бути реалізований різними способами, але існує лише початкова реалізація, коли проект вперше створений. Ви йдете за DefaultOrderчи OrderImplіншим варіантом, щоб уникнути помилкової дихотомії? А що ви робите, коли з'являється більше реалізацій?

І найголовніше ... чому?

Імена мають можливість передати значення. Чому б ви відкинули цю можливість разом із Impl?

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

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

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

• Якщо у вас зараз два, назвіть кожного відповідно до його призначення.

  Приклад: Нещодавно у нас був конкретний клас Context (стосовно посилання на базу даних). Було зрозуміло, що нам потрібно вміти представляти контекст, який був офлайн, тому ім'я Context було використано для нового інтерфейсу (для підтримки сумісності для старих API), і була створена нова реалізація, OfflineContext . Але вгадайте, на що було перейменовано оригінал? Правильно, ContextImpl ( поступається ).

  У цьому випадку DefaultContext , ймовірно, буде нормальним, і люди отримають його, але це не так описово, як це могло б бути. Зрештою, якщо це не офлайн , що це? Тож ми поїхали з: OnlineContext .

Особливий випадок: використання префікса "Я" на інтерфейсах

Один з інших відповідей пропонував використовувати префікс I на інтерфейсах. Переважно, не потрібно цього робити.

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

Приклад: Багато об'єктів можуть бути "EventDispatcher". Для API це повинно відповідати інтерфейсу. Але ви також хочете надати базовий диспетчер подій для делегації. DefaultEventDispatcher було б добре, але це трохи довго, і якщо ви збираєтеся бачити ім'я його часто, ви могли б віддати перевагу використовувати базове ім'я EventDispatcher для конкретного класу, а також здійснювати IEventDispatcher для призначених для користувача реалізацій:

/* Option 1, traditional verbose naming: */
interface EventDispatcher { /* interface for all event dispatchers */ }
class DefaultEventDispatcher implements EventDispatcher {
  /* default event dispatcher */
}

/* Option 2, "I" abbreviation because "EventDispatcher" will be a common default: */
interface IEventDispatcher { /* interface for all event dispatchers */ }
class EventDispatcher implements IEventDispatcher {
  /* default event dispatcher. */
}

Я вирішую іменування у випадку використання інтерфейсу.

Якщо інтерфейс використовується для роз'єднання , то я вибираю Implдля реалізації.

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

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

Я погоджуюся з відповіддю Ніколь (особливо, що інтерфейс, мабуть, не потрібен у більшості випадків), але заради обговорення я викину додаткову альтернативу, окрім OrderImplта DefaultOrder: приховую реалізацію за статичним заводським методом, як Orders.create(). Наприклад:

public final class Orders {
  public static Order create() {
    return new Order() {
      // Implementation goes here.
    };
  }
}

При такому підході реалізація може бути анонімним внутрішнім класом, або це може бути приватний клас з Defaultабо Implв імені, або він може бути названий чимось іншим цілком. Який би вибір не робився, абоненту не потрібно дбати, тому ви отримуєте більше гнучкості зараз і пізніше, коли / якщо ви вирішите змінити його.

Деякі чудові приклади цієї схеми на практиці - класи java.util.Collectionsта java.util.concurrent.Executorsутиліти, методи яких повертають приховані реалізації. Як згадує Ефективна Java (у пункті 1), ця модель може допомогти зменшити "Концептуальну вагу" API.

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

Ви можете назвати інтерфейс з префіксом I (IWever), а потім зробити імплементацію Що завгодно.

Офіційні конвенції Java-коду не розповідають про такий тип імен для інтерфейсів, однак такий спосіб називання допомагає розпізнавати та навігацію.

Я думаю, що, хоча Default може мати сенс у деяких випадках, було б корисніше описати реалізацію. Отже , якщо ваш інтерфейс , UserProfileDAOто ваші реалізації можуть бути UserProfileSQLDAOабо UserProfileLDAPDAOабо що - щось подібне.

по можливості, назвіть його після того, що / як він робить свою справу.

Зазвичай найгірший підхід - це його називання після того, як його слід використовувати.

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

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

Більшість цих відповідей описують, що робиться, а не чому.

Що сталося з принципами ОО? Що Impl розповідає мені про клас та як ним користуватися? Ви повинні бути стурбовані розумінням звичаїв, а не способів їх побудови.

Якщо я створюю інтерфейс Person, що таке PersonImpl? Безглуздо. Принаймні DefaultPerson каже мені, хто не кодував це, не повинен був створювати інтерфейс.

Інтерфейси типізуються для поліморфізму і повинні використовуватися як такі.