Чи повинні імена інтерфейсів починатися з префікса "I"?

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

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

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

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

Отже, моє запитання зводиться до "Чому ми повинні приховувати той факт, що якась частина коду очікує інтерфейс?"

Редагувати

У відповідь на відповідь:

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

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

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

• Обидва мають методи та / або властивості (поведінку);
• Не повинно бути і приватних полів (даних);
• Жоден з них не може бути безпосередньо встановлений;
• Виведення з одного означає реалізацію будь-яких абстрактних методів, якщо тільки похідний тип також не є абстрактним.

Насправді найважливішими відмінностями між класами та інтерфейсами є:

• Інтерфейси не можуть мати приватні дані;
• Учасники інтерфейсу не можуть мати модифікаторів доступу (усі учасники є "загальнодоступними");
• Клас може реалізовувати декілька інтерфейсів (на відміну від загальної можливості успадковувати лише один базовий клас).

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

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

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

Враховуючи це, я, як правило, префіксую свої C # інтерфейси в Iбудь-якому випадку, тому що це .NET-конвенція, яку використовує та обстоює Microsoft. І коли я пояснюю умовам кодування новому розробнику, набагато менше клопоту просто використовувати правила Microsoft, ніж пояснювати, чому у нас є свої "спеціальні" правила.

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

Книга повна хороших речей, але я все одно додав би "Я" до назви інтерфейсу.

Уявіть, у вас є public interface ILogреалізація за замовчуванням public class Log.

Тепер, якщо ви вирішили це зробити public interface Log, раптом вам доведеться змінити клас журналу на public class LogDefaultщось таке в цих рядках. Ви перейшли від одного зайвого персонажа до семи - це, звичайно, марно.

Між теорією та практикою часто існує тонка грань. Теоретично це дійсно гарна ідея, але на практиці це не так добре.

Ну це не про реалізацію інтерфейсу або розширення класу. У випадках з тозами ви все одно знаєте, що робите.

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

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

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

До речі, інтерфейси та класи - це референтні типи в кінці. І це важливо. Отже, саме на цьому має підкреслюватись ваша конвенція про іменування.

Здається, більшість відповідей припускають, що мова програмування - це або Java, або C #, де є концепція (або ключове слово) для інтерфейсів / абстрактних класів. У цих випадках в пристойному IDE відразу видно, з яким типом першого класу має справу і написання public interface IMyClass- непотрібне дублювання. Це як би ви не писали public final FinalMyClass- уявіть, щоб кожне ключове слово було введено в назву класів.

Однак, на мою думку, у C ++ ситуація дещо інша, оскільки треба зануритися у файл заголовка і побачити, чи є у класу якісь віртуальні методи, щоб з’ясувати, чи це абстрактний клас. У цьому випадку я чітко бачу аргумент для написання class AbstractMyClass.

Тож моя відповідь була б: Це залежить від мови програмування.

Оновлено 2016: 2 роки досвіду роботи на C ++ пізніше, я б зараз, мабуть, вважав би поганою практикою встановлювати префікси імен класів Abstract, хоча я б сказав, що, ймовірно, є кодові бази, які є настільки складними, що може мати сенс.

Дотримуйтесь ідіоми мови, якою ви користуєтесь.

Кожна мова має свої ідіоми та вказівки щодо кодування. Наприклад, у C # ідіоматично встановлювати префікси інтерфейсів із I. У Go, це не так.

У своєму (Java) коді я схильний мати цю умову в API, які я піддаю абонентам:

• Функціональність забезпечується через інтерфейси, і ніколи за класами.
• Нефункціональні частини - це заняття.

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

Що стосується умов іменування, інтерфейси мають тенденцію до відображення або іменників дійових осіб (наприклад, FooBarWatcher), або прикметників (наприклад, FooBarWatchable), і чисті класи даних, і перерахування відображають неактивні іменники (наприклад, FooBarStatus); IDE може керувати споживачами API без спеціальних угод про іменування. Винятки слідують звичайним правилам Java ( FooBarException, FooBarError, FooBarFault) звичайно.

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