Konwencje nazewnictwa protokołu Swift [zamknięte]

53

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?

Michael Daw
źródło
Ogólnie terminologia stosowana w nazwie protokołu powinna przekazywać umiejętność. Equatableklasy można zrównać, NSCopyingklasy można skopiować, itp. Jedynym wyjątkiem, który przychodzi na myśl, są delegaci i źródła danych, którymi są SomethingDelegatelub SomethingDataSource. Myślę, że różnica polega na tym, że klasy będące właścicielami będą miały coś takiego var dataSource: SomethingDataSource, ale czegoś takiego nie zobaczysz var foo: Equatable.
Ben Leggiero

Odpowiedzi:

82

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.

amon
źródło
6
FooDelegate jest również powszechny (przynajmniej dla delegatów, którzy prawie zawsze są protokołami ... może faktycznie zawsze)
Stripes
3
Wytyczne dotyczące projektowania interfejsu API Swift: swift.org/documentation/api-design-guidelines >> Protokoły opisujące, co należy odczytać jako rzeczowniki (np. Collection). >> Protokoły opisujące zdolność należy nazwać przy użyciu sufiksów zdolnych, ible lub ing (np. Equatable, ProgressReporting).
David James
1
@amon jak mam nazwać protokół dla mojej klasy BluetoothService lub UserDataManager? „... ing” lub „... zdolny” nie pasuje tutaj i chciałbym uniknąć sufiksu „Protokół”, jakieś pomysły? Zgodnie z wytycznymi projektowymi API, protokół powinien być w tym przypadku rzeczownikiem takim jak BluetoothService, ale jaka nazwa powinna mieć implementację? BluetoothServiceImpl? Btw. po wielu przykładach, które widziałem, myślę, że C # ma najlepszą konwekcję z prefiksem „I”, takim jak IAnything, IEquatable, ISmthAware: D
Wojciech Kulik
1
@WojciechKulik Nie jestem pewien, jakie dobre nazwiska mogą być w twoim przypadku. Wiele zależy od sposobu wykorzystania tych protokołów. Jednak… Usługi i… Nazwy menedżerów mogą być rodzajem zapachu kodu - nazwa jest zasadniczo taka sama, jeśli usuniesz ten przyrostek. Niektóre nazwy do rozważenia: Bluetooth, BluetoothConnecting, BluetoothProtocol, UserData, UserDataRepository, UserDataWriting, UserDataProtocol.
amon
1
Nazewnictwo @DeclanMcKenna może być dość subiektywne, a wybór nazwy nie zawsze jest oczywisty. Ale w wielu przypadkach należy użyć protokołów do wyrażenia pewnych ściśle określonych możliwości (porównaj także zasadę segregacji interfejsu).
amon