Swift a considérablement mûri au cours des années qui ont suivi cette réponse. Les directives de conception indiquent désormais :
Les protocoles décrivant ce que quelque chose est devrait se lire comme des noms (par exemple Collection
).
Les protocoles qui décrivent une capacité doivent être nommés en utilisant les suffixes able
, ible
ou ing
(par exemple Equatable
, ProgressReporting
).
Merci à David James d' avoir remarqué cela!
Réponse originale
Utiliser une forme de notation hongroise peut être une bonne idée - représenter des concepts importants qui ne peuvent pas être encodés dans le système de types. Cependant, le fait que certains identificateurs fassent référence à un protocole fait partie du système de types de Swift (et C #) et, de ce fait, tout préfixe ou suffixe n’ajoute que du bruit. Les préfixes ou suffixes clairs sont une meilleure idée pour des concepts tels que les exceptions ou les événements.
En l'absence d'un guide de style officiel pour Swift, nous devons inventer le nôtre ou emprunter des guides ou du code existants. Par exemple, le guide de style Objective-C pour Cocoa contient cette section:
Les protocoles doivent être nommés en fonction de la manière dont ils regroupent les comportements:
La plupart des protocoles regroupent des méthodes qui ne sont associées à aucune classe en particulier. Ce type de protocole doit être nommé afin que le protocole ne soit pas confondu avec une classe. Une convention courante consiste à utiliser une forme gerund (“... ing”):
NSLocking
- Bien.
NSLock
- Pauvre (semble être un nom pour une classe).
Certains protocoles regroupent un certain nombre de méthodes non liées (plutôt que de créer plusieurs petits protocoles distincts). Ces protocoles ont tendance à être associés à une classe qui est l'expression principale du protocole. Dans ces cas, la convention est de donner au protocole le même nom que la classe.
Un exemple de ce type de protocole est le NSObject
protocole. Ce protocole regroupe les méthodes que vous pouvez utiliser pour interroger n'importe quel objet sur sa position dans la hiérarchie de classes, pour lui faire appeler des méthodes spécifiques et pour incrémenter ou décrémenter son décompte de références. Étant donné que la NSObject
classe fournit l'expression principale de ces méthodes, le protocole porte le nom de la classe.
Toutefois, l'avis du deuxième point n'est plus applicable:
L'espace de noms des classes et des protocoles étant unifié dans Swift, le NSObject
protocole dans Objective-C est remappé NSObjectProtocol
dans Swift. ( source )
Ici, le …Protocol
suffixe a été utilisé afin de distinguer le protocole de la classe.
La bibliothèque standard Swift contient les protocoles Equatable
, Comparable
et Printable
. Celles-ci n'utilisent pas la forme “… ing” de cacao, mais plutôt le suffixe “… capable” de déclarer que toute instance de ce type doit prendre en charge une certaine opération.
Conclusion
Dans quelques cas où un protocole n'a qu'une seule implémentation pertinente, un suffixe «… Protocole» peut avoir un sens, de sorte que la classe et le protocole puissent avoir le même nom. Toutefois, cela devrait être limité à de tels cas seulement.
Sinon, le nom devrait être un nom indiquant les opérations contenues dans ce protocole. L'utilisation d'un verbe «… ing» ou «… capable» peut constituer un bon point de départ et il est peu probable que ces noms entrent en conflit avec les noms de classe.
Le nom EquatableProtocol
n'est pas recommandé . Le nom Equatable
ou Equating
serait beaucoup mieux, et je ne m'attends pas à ce qu'une classe ait le nom Equatable
. Dans ce cas, le Protocol
suffixe est bruit.