Swift-style-guide: Dénomination du protocole

Je pense qu'il serait difficile de traduire le style de nom C# en Swift. Le « I » pour l'interface fonctionne dans .NET car les différences d'espace de noms.

Quant aux gérondifs ("able" et "ing"), je pense qu'ils fonctionnent de la même manière qu'en anglais :
"Un gérondif est un nom composé d'un verbe en ajoutant "-ing".

Par exemple : j'ai besoin de hacher (verbe) cette classe, est-elle hachable (gerund) ? Je veux comparer (verbe), cette classe est-elle comparable (gérondif) ?

Si vous regardez C#, ils n'utilisent pas non plus de gérondif pour toutes les interfaces. Prenez le Point (classe) et IPoint (interface qui implémente X et Y). Faire quelque chose de pointable serait un peu trompeur.

Les protocoles tels que UITableViewDelegate et UITableViewDataSource me conviennent. Personnellement, je n'ai aucun problème avec le suffixe ...Protocol mais je ne le voudrais pas en règle générale. Parfois, "capable" fonctionne mieux, parfois d'autres suffixes ont du sens, tels que ...Délégué ou ...DataSource.

Je crois que s'ils étaient créés aujourd'hui, ils s'appelleraient UITableViewDelegateType et UITableViewDataSourceType. Greg Heo appelle cela "est un": http://www.skilled.io/gregheo/what-the-55-swift-standard-library-protocols-taught-me

Beaucoup de mes propres protocoles n'encapsulent qu'une seule fonction ou propriété. Swift n'a aucun problème à nommer le protocole de la même manière, et je pense que c'est une approche très claire.

protocol bool {
   var bool: Bool {get}
}

struct Struct: bool {
   let bool = true
}

J'utiliserai la convention de nommage des délégués et des sources de données normale si nécessaire, mais pour les protocoles qui sont simplement utilisés pour composer des objets, je viens de mettre Protocol dans le nom. Je ne sais pas si c'est une bonne pratique ou non, quand j'ai fait des recherches, je n'ai trouvé aucune information.

protocol AlertModalProtocol {
func titleText() -> String
func messageText() -> String
}

struct NewUserAlertModal: AlertModalProtocol {

    func titleText() -> String {
        return "Welcome new user"
    }

    func messageText() -> String {
        return "Thanks for joining the app."
    }
}

Le suffixe "Type" semble suivre le chemin du dinosaure, même si j'ai pensé avoir vu passer une proposition d'utiliser "Protocole" comme le fait @mitchellporter .

D'après les directives de conception de l'API Swift :

Les protocoles qui décrivent ce qu'est quelque chose doivent être interprétés comme des noms (par exemple, Collection). Les protocoles qui décrivent une capacité doivent être nommés à l'aide des suffixes able, ible ou ing (par exemple, Equatable, ProgressReporting).

C'est intéressant. D'après mon expérience, ThingType a été nécessaire alors que Thing aurait traditionnellement été une classe non abstraite. (c'est-à-dire que Thing est un type concret qui implémente ThingType, et d'autres types qui sont plus spécifiques implémentent également ThingType.) NSObjectProtocol est un exemple de ce genre de chose.

J'ajouterai du texte dans le sens du brouillon des directives de conception de l'API.

RAPIDE
En regardant le code de quelqu'un d'autre, j'ai rencontré un problème, que les protocoles qui décrivent, qu'est-ce que c'est, quand ce sont des noms, sont tranquillement gênants, car je le confond souvent avec les méthodes de classe. Pour résoudre ce problème, je pense que la meilleure façon d'utiliser la règle suivante :

When the protocol name is a noun - write ..Protocol (yes, even in swift);
par exemple PhotoModuleProtocole
When the protocol is an adverb or an adjective - write ..able, ..ing and so on;
Ex. Testable

À mon avis, il vaut mieux expliquer explicitement maintenant ce que c'est que de compter le temps pour reconnaître le code de quelqu'un, que les trucs de Swift hipster.

J'ai posté mon dernier commentaire en 2015... depuis lors, j'ai migré principalement en utilisant ce que @gregheo a partagé plus tôt :

Les protocoles qui décrivent ce qu'est quelque chose doivent être interprétés comme des noms (par exemple, Collection). Les protocoles qui décrivent une capacité doivent être nommés à l'aide des suffixes able, ible ou ing (par exemple, Equatable, ProgressReporting).

Ainsi, par exemple, il existe normalement un type de modèle de base qui ressemblera à ceci :

protocol BaseType {
    var objectId: String { get set }
    var createdAt: NSDate? { get set }
    var updatedAt: NSDate? { get set }
    func toJSON() -> [String: AnyObject]
    static func from(json: [String: AnyObject]) -> AnyObject
}

Étant donné que tous les modèles de l'application auront besoin de cette fonctionnalité, ils seront tous conformes à BaseType . En fait, j'ai nommé ce type de base d'après le nom de l'application, donc si le nom de votre application était Instagram ce serait InstagramType . Maintenant que j'y pense, inclure Type dans le nom semble un peu inutile... il n'y a aucune raison pour que vous ne puissiez pas le nommer BaseModel , InstagramModel ou même seulement Model .

En ce qui concerne les protocoles qui décrivent les capacités, j'ai également utilisé les suffixes de type able, ible et ing.

J'ai arrêté d'utiliser le mot protocol dans mes noms parce qu'il me paraissait redondant et j'avais aussi l'impression de l'utiliser pour que tout le monde comprenne facilement "Hé, c'est un protocole, pas une classe" qui me semblait faux puisque les protocoles sont censés être considérés comme égaux aux classes, sinon au-dessus d'elles, dans swift.

Donc, plutôt que de les distinguer en incluant le protocole dans le nom, je le laisse de côté. C'est juste ce qui me semble juste, je ne prétends pas que tout cela soit bien ou mal. Même des années plus tard, je découvre toujours de nouvelles choses dans Swift et j'ai renoncé à essayer de tout comprendre. J'essaye vraiment d'expérimenter et de voir ce que la communauté propose à ce stade :)

Pourtant, nommer les protocoles par nom entraîne l'ajout d'un mot (cela peut être "..Model", "..Type" et ainsi de suite) pour déterminer qu'il s'agit d'un protocole et non d'une classe. Change juste le type de mot à utiliser =)