Conventions de dénomination du protocole Swift [fermées]


53

Venant d'un arrière-plan principalement c #, je suis habitué à utiliser le terme "interface" pour décrire un objet sans implémentation définissant le comportement. En c #, la convention est d’ajouter des noms d’interface avec "I", comme dans IEnumerable, etc.

Bien entendu, le concept a différents noms dans différentes langues. Dans Swift, le même concept s'appelle un "protocole". Lorsque je développe des protocoles, j'ai souvent des noms très similaires pour le protocole et une classe qui l'implémente. Jusqu'ici, j'ai ajouté le mot "protocole" à ces objets de la même manière que j'utiliserais "I" en c #, comme dans EnumerableProtocol, etc.

Avez-vous des idées sur une convention de nommage pour les protocoles dans swift?



En général, la terminologie utilisée dans un nom de protocole devrait indiquer une capacité. Equatableles classes peuvent être assimilées, les NSCopyingclasses peuvent être copiées, etc. La seule exception qui me vient à l’esprit est les délégués et les sources de données, qu’ils soient SomethingDelegateou SomethingDataSource. Je pense que la distinction est que les classes propriétaires auront quelque chose comme var dataSource: SomethingDataSource, mais vous ne verrez pas quelque chose comme var foo: Equatable.
Ben Leggiero

Réponses:


82

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, ibleou 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:

Noms de classe et de protocole

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 NSObjectprotocole. 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 NSObjectclasse 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 NSObjectprotocole dans Objective-C est remappé NSObjectProtocoldans Swift. ( source )

Ici, le …Protocolsuffixe a été utilisé afin de distinguer le protocole de la classe.

La bibliothèque standard Swift contient les protocoles Equatable, Comparableet 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 EquatableProtocoln'est pas recommandé . Le nom Equatableou Equatingserait beaucoup mieux, et je ne m'attends pas à ce qu'une classe ait le nom Equatable. Dans ce cas, le Protocolsuffixe est bruit.


6
FooDelegate est également courant (du moins pour les délégués, qui sont presque toujours des protocoles ... peut-être même toujours)
Stripes

3
Directives de conception de l'API Swift: swift.org/documentation/api-design-guidelines >> Les protocoles décrivant ce qui se passe doivent se lire comme des noms (par exemple, Collection). >> Les protocoles décrivant une capacité doivent être nommés en utilisant les suffixes capable, ible, ou ing (par exemple, Equatable, ProgressReporting).
David James

1
@ amon comment nommer le protocole pour ma classe BluetoothService ou UserDataManager? "... ing" ou "... capable" ne convient pas ici et j'aimerais éviter le suffixe "Protocole", des idées? Selon les directives de conception d'API, le protocole devrait être dans ce cas un nom comme BluetoothService, mais quel nom devrait alors avoir la mise en œuvre? BluetoothServiceImpl? Btw. après de nombreux exemples que j'ai vus, je pense que C # a la meilleure convetion avec le préfixe "I" comme IAnything, IEquatable, ISmthAware: D
Wojciech Kulik

1
@ WojciechKulik Je ne suis pas sûr de ce que les bons noms pourraient être dans votre cas. Beaucoup dépend de la façon dont ces protocoles seront utilisés. Cependant,… Les noms de service et de gestionnaire peuvent être une sorte d'odeur de code. Le nom est fondamentalement le même si vous supprimez ce suffixe. Quelques noms à prendre en compte: Bluetooth, BluetoothConnecting, BluetoothProtocol, UserData, UserDataRepository, UserDataWriting, UserDataProtocol.
amon

1
@DeclanMcKenna nommer peut devenir assez subjectif, et quel nom choisir n'est pas toujours évident. Mais dans de nombreux cas, les protocoles doivent être utilisés pour exprimer certaines capacités étroitement définies (comparez également le principe de ségrégation d’interfaces).
amon
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.