Proveniente principalmente da uno sfondo c #, sono abituato a usare il termine "interfaccia" per descrivere un oggetto senza implementazione che definisce il comportamento. In c #, la convenzione è di anteporre nomi di interfaccia con "I", come in IEnumerable, ecc.

Naturalmente, il concetto ha nomi diversi in diverse lingue. In Swift, lo stesso concetto è chiamato "protocollo". Quando sto sviluppando protocolli, ho spesso nomi molto simili per il protocollo e una classe che lo implementa. Finora ho aggiunto la parola "protocollo" a questi oggetti nello stesso modo in cui userei "I" in c #, come in EnumerableProtocol, ecc.

Qualche idea su una convenzione di denominazione per i protocolli in tempi rapidi?

Swift è maturato in modo significativo negli anni da quando questa risposta è stata scritta. Le linee guida di progettazione ora affermano :

• I protocolli che descrivono cosa è qualcosa devono essere letti come sostantivi (ad es Collection.).

• I protocolli che descrivono una capacità devono essere denominati con i suffissi able, ibleo ing(per esempio Equatable, ProgressReporting).

Grazie a David James per averlo individuato!

Risposta originale

Usare una qualche forma di notazione ungherese può essere una buona idea: rappresentare concetti importanti che non possono essere codificati all'interno del sistema dei tipi. Tuttavia, il fatto che alcuni identificatori si riferiscano a un protocollo fa parte del sistema di tipi in Swift (e C #), e come tale qualsiasi prefisso o suffisso aggiunge solo rumore. Chiari prefissi o suffissi sono un'idea migliore per concetti come eccezioni o eventi.

In assenza di una guida di stile ufficiale per Swift, dobbiamo inventare la nostra o prendere in prestito da guide o codici esistenti. Ad esempio, la guida di stile Objective-C per Cocoa contiene questa sezione:

Nomi di classi e protocolli

I protocolli dovrebbero essere nominati in base al modo in cui raggruppano i comportamenti:

• La maggior parte dei protocolli raggruppa metodi correlati che non sono associati ad alcuna classe in particolare. Questo tipo di protocollo deve essere denominato in modo che il protocollo non venga confuso con una classe. Una convenzione comune è quella di utilizzare un modulo gerundio ("... ing"):

  NSLocking- Buono.
  NSLock- Scarso (sembra un nome per una classe).

• Alcuni protocolli raggruppano una serie di metodi non correlati (piuttosto che creare diversi piccoli protocolli separati). Questi protocolli tendono ad essere associati a una classe che è l'espressione principale del protocollo. In questi casi, la convenzione prevede di assegnare al protocollo lo stesso nome della classe.

  Un esempio di questo tipo di protocollo è il NSObjectprotocollo. Questo protocollo raggruppa metodi che è possibile utilizzare per interrogare qualsiasi oggetto sulla sua posizione nella gerarchia di classi, per fare in modo che invochi metodi specifici e per aumentare o diminuire il conteggio dei riferimenti. Poiché la NSObjectclasse fornisce l'espressione primaria di questi metodi, il protocollo prende il nome dalla classe.

Tuttavia, la consulenza del secondo punto non è più applicabile:

Poiché lo spazio dei nomi di classi e protocolli è unificato in Swift, il NSObjectprotocollo in Objective-C viene rimappato NSObjectProtocolin Swift. ( fonte )

Qui, il …Protocolsuffisso è stato usato per chiarire il protocollo dalla classe.

La libreria standard Swift contiene i protocolli Equatable, Comparablee Printable. Questi non usano il modulo "... ing" di Cocoa, ma piuttosto il suffisso "... capace" per dichiarare che qualsiasi istanza di questo tipo deve supportare una determinata operazione.

Conclusione

In alcuni casi in cui un protocollo ha solo un'implementazione pertinente, un suffisso "... Protocol" può avere senso in modo che la classe e il protocollo possano avere lo stesso nome. Tuttavia, questo dovrebbe essere limitato a tali casi.

Altrimenti, il nome dovrebbe essere un nome che riflette quali operazioni contiene questo protocollo. L'uso di una forma "... ing" o "... capace" di un verbo può essere un buon punto di partenza e è improbabile che tali nomi siano in conflitto con i nomi delle classi.

Il nome EquatableProtocolè non consigliabile . Il nome Equatableo Equatingsarebbe molto meglio, e non mi aspetto che nessuna classe abbia il nome Equatable. In questo caso, il Protocolsuffisso è rumore.