Чи повинен кожен клас, який я пишу, дотримуватися інтерфейсу?

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

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

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

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

Причина наявності інтерфейсів полягає в тому, що це спрощує поліморфізм. Це означає, що ви можете надсилати екземпляри за контрактом, а не знати їх фактичну реалізацію. Наприклад, ви можете надіслати "Читач" методу, щоб такий викликаний метод міг використовувати його метод "read ()". Заявивши інтерфейс "Reader", ви можете зробити будь-який об'єкт відповідним цьому договору, реалізуючи вказані ним методи. Таким чином, будь-який абонент може припустити, що існуватимуть певні методи, навіть якщо об'єкти, що лежать в основі договору, можуть бути абсолютно іншими.

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

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

Якщо у вас є лише ОДИН ланцюг успадкування (baseclass-> підклас) або просто база, або у вас немає необхідності фактично ПАСУВАТИ пов’язані об’єкти комусь іншому або використовувати їх загально, тоді ви не додаватимете реалізацій інтерфейсу, оскільки це поняття тоді марний.

Якщо ви не впевнені, чи справді вам потрібні інтерфейси, ви, мабуть, цього не зробите. Це суть принципу YAGNI. Коли вам потрібно мати можливість замінити реалізацію, тоді ви введете інтерфейс.

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

Зазвичай ми використовуємо "інтерфейс", щоб означати "клас Java, визначений за допомогою interfaceключового слова" або "клас C ++ з лише публічними, чистими віртуальними функціями". Це корисні абстракції, оскільки вони відокремлюють інтерфейс класу від його реалізації.

Зважаючи на це, використовуйте інтерфейси, коли це доречно.

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

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

Зауважте вищенаведені слова: "може" бути кандидатом ", може бути" корисним. Не існує жорсткого і швидкого правила, яке говорить "так" або "ні" для даної ситуації.

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

interface I {
  int getA()
  int getB()
  ...
  int getY()
  int getZ()
}

class C : I {
  int getA() { ... }
  int getB() { ... }
  ...
  int getY() { ... }
  int getZ() { ... }
}

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

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

Знущальні рамки

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

Ін'єкційна залежність

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

Ці підходи узагальнені в принципі D з принципів SOLID . Треба це - використовувати абстракції, а не конкременти.

Як і самі дизайнерські шаблони, коли їх використовувати - це виклик судження. Справа в тому, щоб зрозуміти, наскільки корисні інтерфейси, а не проставляти їх на своїх заняттях, тому що ви вважаєте, що це потрібно. Існує гарне обговорення різних достоїнств DIP і YAGNI тут .