Ich komme hauptsächlich aus dem C # -Hintergrund und bin es gewohnt, den Begriff "Schnittstelle" zu verwenden, um ein Objekt ohne Implementierung zu beschreiben, die das Verhalten definiert. In c # besteht die Konvention darin, Schnittstellennamen wie in IEnumerableusw. ein "I" voranzustellen .

Natürlich hat das Konzept verschiedene Namen in verschiedenen Sprachen. In Swift wird dasselbe Konzept als "Protokoll" bezeichnet. Wenn ich Protokolle entwickle, habe ich oft sehr ähnliche Namen für das Protokoll und eine Klasse, die es implementiert. Bisher habe ich an diese Objekte das Wort "protocol" angehängt, so wie ich "I" in c #, wie in EnumerableProtocolusw. verwendet habe.

Überlegungen zu einer Namenskonvention für Protokolle in Kürze?

Swift ist in den Jahren seit dieser Antwort deutlich gereift. In den Gestaltungsrichtlinien heißt es nun :

• Protokolle, die beschreiben, was etwas ist, sollten als Substantive gelesen werden (z Collection. B. ).

• Protokolle , die eine beschreiben Fähigkeit sollte mit den Suffixen benannt werden able, ibleoder ing(zB Equatable, ProgressReporting).

Vielen Dank an David James, der das entdeckt hat!

Ursprüngliche Antwort

Die Verwendung einer Form der ungarischen Notation kann eine gute Idee sein - um wichtige Konzepte darzustellen, die im Typensystem nicht codiert werden können. Die Tatsache, dass sich ein Bezeichner auf ein Protokoll bezieht, ist jedoch Teil des Typsystems in Swift (und C #) und als solches fügt jedes Präfix oder Suffix nur Rauschen hinzu. Klare Präfixe oder Suffixe sind eine bessere Idee für Konzepte wie Ausnahmen oder Ereignisse.

Da es keinen offiziellen Styleguide für Swift gibt, müssen wir uns einen eigenen ausdenken oder ihn von vorhandenen Guides oder Codes ausleihen. Der Objective-C-Styleguide für Cocoa enthält beispielsweise folgenden Abschnitt:

Klassen- und Protokollnamen

Protokolle sollten nach dem Gruppierungsverhalten benannt werden:

• Die meisten Protokolle gruppieren verwandte Methoden, die keiner bestimmten Klasse zugeordnet sind. Dieser Protokolltyp sollte so benannt werden, dass das Protokoll nicht mit einer Klasse verwechselt wird. Eine übliche Konvention ist die Verwendung einer Gerundform ("ing"):

  NSLocking- Gut.
  NSLock- Arm (scheint ein Name für eine Klasse zu sein).

• Einige Protokolle gruppieren eine Reihe nicht verwandter Methoden (anstatt mehrere separate kleine Protokolle zu erstellen). Diese Protokolle sind in der Regel mit einer Klasse verknüpft, die der Hauptausdruck des Protokolls ist. In diesen Fällen lautet die Konvention, dem Protokoll den gleichen Namen wie der Klasse zu geben.

  Ein Beispiel für diese Art von Protokoll ist das NSObjectProtokoll. Mit diesem Protokoll werden Methoden gruppiert, mit denen Sie ein Objekt nach seiner Position in der Klassenhierarchie abfragen, bestimmte Methoden aufrufen und seine Referenzanzahl erhöhen oder verringern können. Da die NSObjectKlasse den primären Ausdruck dieser Methoden bereitstellt, wird das Protokoll nach der Klasse benannt.

Der Hinweis des zweiten Punktes gilt jedoch nicht mehr:

Da der Namespace von Klassen und Protokollen in Swift vereinheitlicht ist, wird das NSObjectProtokoll in Objective-C NSObjectProtocolin Swift neu zugeordnet. ( Quelle )

Hier wurde das …ProtocolSuffix verwendet, um das Protokoll von der Klasse zu trennen.

Der Swift Standard Library enthält die Protokolle Equatable, Comparableund Printable. Diese verwenden nicht das Cocoa-Formular „… ing“, sondern das Suffix „… able“, um zu deklarieren, dass jede Instanz dieses Typs eine bestimmte Operation unterstützen muss.

Fazit

In einigen Fällen, in denen ein Protokoll nur eine relevante Implementierung hat, kann das Suffix „… Protocol“ sinnvoll sein, damit Klasse und Protokoll denselben Namen haben können. Dies sollte jedoch nur auf solche Fälle beschränkt sein.

Andernfalls sollte der Name ein Substantiv sein, das angibt, welche Operationen in diesem Protokoll enthalten sind. Die Verwendung einer „… ing“ - oder „… able“ -Form eines Verbs kann ein guter Ausgangspunkt sein, und es ist unwahrscheinlich, dass solche Namen mit Klassennamen in Konflikt stehen.

Der Name EquatableProtocolist nicht zu empfehlen . Der Name Equatableoder Equatingwäre weitaus besser, und ich erwarte nicht, dass eine Klasse den Namen hat Equatable. In diesem Fall ist das ProtocolSuffix Rauschen.