Pochodząc głównie z języka c #, przyzwyczaiłem się używać terminu „interfejs” do opisywania obiektu bez implementacji, która określa zachowanie. W języku c # konwencja polega na dodawaniu nazw interfejsów do „I”, jak w IEnumerableitd.

Oczywiście koncepcja ma różne nazwy w różnych językach. W Swift ta sama koncepcja nazywa się „protokołem”. Kiedy opracowuję protokoły, często mam bardzo podobne nazwy protokołu i klasy, która go implementuje. Do tej pory dodawałem słowo „protokół” do tych obiektów w ten sam sposób, w jaki używałem „I” w c #, jak w EnumerableProtocolitp.

Masz jakieś przemyślenia na temat konwencji nazewnictwa protokołów w krótkim czasie?

Swift dojrzał znacznie od lat, odkąd napisano tę odpowiedź. Wytyczne projektowe określają teraz :

• Protokoły opisujące, co to jest, powinny być odczytywane jako rzeczowniki (np Collection.)

• Protokoły opisujące możliwości powinny być nazywane za pomocą przyrostków able, iblelub ing(np Equatable, ProgressReporting).

Dziękuję Davidowi Jamesowi za zauważenie tego!

Oryginalna odpowiedź

Dobrym pomysłem może być użycie jakiejś formy notacji węgierskiej - do przedstawienia ważnych pojęć, których nie można zakodować w systemie pisma. Jednak fakt, że jakiś identyfikator odnosi się do protokołu, jest częścią systemu typów w Swift (i C #) i jako taki każdy prefiks lub sufiks tylko dodaje szum. Wyczyść przedrostki lub przyrostki są lepszym pomysłem na pojęcia takie jak wyjątki lub zdarzenia.

W przypadku braku oficjalnego przewodnika po stylu dla Swift, musimy wymyślić własny lub pożyczyć z istniejących przewodników lub kodu. Na przykład przewodnik po stylu C celu dla kakao zawiera tę sekcję:

Nazwy klas i protokołów

Protokoły należy nazwać zgodnie z tym, w jaki sposób grupują zachowania:

• Większość protokołów grupuje metody powiązane, które nie są powiązane z żadną konkretną klasą. Ten typ protokołu powinien zostać nazwany, aby nie mylić protokołu z klasą. Powszechną konwencją jest stosowanie formy gerund („... ing”):

  NSLocking- Dobry.
  NSLock- Słaba (wydaje się, że jest to nazwa klasy).

• Niektóre protokoły grupują wiele niepowiązanych metod (zamiast tworzyć kilka oddzielnych małych protokołów). Protokoły te są zwykle powiązane z klasą, która jest głównym wyrażeniem protokołu. W takich przypadkach konwencja polega na nadaniu protokołowi tej samej nazwy co klasa.

  Przykładem tego rodzaju protokołu jest NSObjectprotokół. Ten protokół grupuje metody, których można użyć do zapytania dowolnego obiektu o jego pozycję w hierarchii klas, w celu wywołania określonych metod oraz zwiększenia lub zmniejszenia liczby referencji. Ponieważ NSObjectklasa zapewnia podstawowe wyrażenie tych metod, protokół jest nazwany na cześć klasy.

Jednak rada z drugiego punktu nie ma już zastosowania:

Ponieważ przestrzeń nazw klas i protokołów jest ujednolicona w Swift, NSObjectprotokół w Objective-C jest odwzorowany NSObjectProtocolw Swift. ( źródło )

Tutaj zastosowano …Protocolsufiks, aby ujednoznacznić protokół z klasy.

Swift standardowa biblioteka zawiera protokoły Equatable, Comparableoraz Printable. Nie używają one formy „… ing” kakao, lecz sufiks „… zdolny” do zadeklarowania, że ​​każda instancja tego typu musi obsługiwać określoną operację.

Wniosek

W kilku przypadkach, gdy protokół ma tylko jedną istotną implementację, przyrostek „… Protokół” może mieć sens, aby klasa i protokół mogły mieć tę samą nazwę. Powinno to jednak ograniczać się tylko do takich przypadków.

W przeciwnym razie nazwa powinna być rzeczownikiem odzwierciedlającym operacje, które zawiera ten protokół. Użycie formy „… ing” lub „… zdolnej” czasownika może być dobrym punktem wyjścia i jest mało prawdopodobne, aby takie nazwy kolidowały z nazwami klas.

Nazwa nieEquatableProtocol jest godna polecenia . Nazwa Equatablelub Equatingbyłaby o wiele lepsza i nie oczekuję, że żadna klasa będzie miała taką nazwę Equatable. W tym przypadku Protocolsufiksem jest hałas.