Виходячи з переважно c # фону, я звик використовувати термін "інтерфейс" для опису об'єкта без реалізації, який визначає поведінку. У c # умовою є додавання назв інтерфейсу з "Я", як у IEnumerable, тощо.

Звичайно, концепція має різні назви різними мовами. У Свіфта те саме поняття називається "протокол". Коли я розробляю протоколи, у мене часто є дуже схожі назви для протоколу та класу, який його реалізує. Поки що я додав слово "протокол" до цих об'єктів так само, як я б використав "Я" в c #, як EnumerableProtocolі т.д.

Будь-які думки щодо угоди про іменування для протоколів у швидкій формі?

Свіфт суттєво дозрів за роки, коли була написана відповідь. Настанови проектування тепер зазначають :

• Протоколи, що описують, що щось є, слід читати як іменники (наприклад Collection).

• Протоколи , які описують можливості повинні бути названі з допомогою суфіксів able, ibleабо ing(наприклад Equatable, ProgressReporting).

Дякую Девіду Джеймсу, що помітили це!

Оригінальний відповідь

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

За відсутності офіційного посібника зі стилів для Swift, ми повинні придумати власні або запозичити існуючі путівники чи код. Наприклад, посібник зі стилю Objective-C для какао містить цей розділ:

Імена класів та протоколів

Протоколи повинні бути названі відповідно до того, як вони групують поведінку:

• Більшість протоколів групують пов'язані методи, які не асоціюються з жодним класом зокрема. Цей тип протоколу має бути названий таким чином, щоб протокол не плутався з класом. Поширеною умовою є використання форми герунду ("... ing"):

  NSLocking- Добре.
  NSLock- Погано (здається, ім'я для класу).

• Деякі протоколи групують ряд споріднених методів (а не створюють кілька окремих невеликих протоколів). Ці протоколи, як правило, асоціюються з класом, який є основним виразом протоколу. У цих випадках умовою є надання протоколу тієї ж назви, що і клас.

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

Однак поради другого пункту більше не застосовуються:

Оскільки простір імен класів і протоколів уніфікований у Swift, NSObjectпротокол в Objective-C перезазначений NSObjectProtocolу Swift. ( джерело )

Тут …Protocolсуфікс був використаний для відмежування протоколу від класу.

Стандартна бібліотека Swift містить протоколи Equatable, Comparableі Printable. Вони не використовують форму «…» какао, а швидше суфікс «… здатний» заявляти, що будь-який екземпляр цього типу повинен підтримувати певну операцію.

Висновок

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

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

Назва EquatableProtocolце не рекомендується . Ім'я Equatableабо Equatingбуло б набагато краще, і я не очікую, що будь-який клас матиме ім'я Equatable. У цьому випадку Protocolсуфікс - шум.