Swiftプロトコルの命名規則[終了]


53

主にC#のバックグラウンドから来て、私は動作を定義する実装のないオブジェクトを記述するために「インターフェース」という用語を使用することに慣れています。C#ではIEnumerable、などのように、インターフェイス名の先頭に「I」を付けます。

もちろん、コンセプトは異なる言語で異なる名前を持っています。Swiftでは、同じ概念が「プロトコル」と呼ばれます。プロトコルを開発しているとき、プロトコルとそれを実装するクラスの名前がよく似ています。これまでのところ、C#で「I」を使用するのと同じ方法で、これらのオブジェクトに「プロトコル」という単語を追加していますEnumerableProtocol

迅速なプロトコルの命名規則についての考えはありますか?



一般に、プロトコル名で使用される用語は能力を伝える必要があります。Equatableクラスは、同一視することが可能NSCopyingに頭に浮かぶ唯一の例外など、クラスがによってコピーすることができます、デリゲートとデータソース、ですSomethingDelegateSomethingDataSource。違いは所有クラスには似たようなものがあるがvar dataSource: SomethingDataSource、似たようなものが見えないことだと思うvar foo: Equatable
ベンレジェロ

回答:


82

Swiftは、この回答が書かれてから数年で大幅に成熟しました。設計ガイドラインには次のように記載されています

  • 何が何かであるを説明するプロトコルは、名詞(例Collection)として読まれるべきです。

  • 記述プロトコル機能は、接尾辞を使用して命名されなければならないableibleまたはing(例えばEquatableProgressReporting)。

これを見つけてくれたDavid Jamesに感謝します!

元の回答

型システム内でエンコードできない重要な概念を表すために、何らかの形式のハンガリー記法を使用することは良い考えです。ただし、一部の識別子がプロトコルを参照するという事実、Swift(およびC#)の型システムの一部であり、したがって、プレフィックスまたはサフィックスはノイズを追加するだけです。例外やイベントなどの概念には、明確な接頭辞または接尾辞が適しています。

Swiftの公式スタイルガイドがない場合、独自のガイドを作成するか、既存のガイドまたはコードを借用する必要があります。たとえば、CocoaのObjective-Cスタイルガイドには次のセクションが含まれています。

クラス名とプロトコル名

プロトコルは、動作をグループ化する方法に従って名前を付ける必要があります。

  • ほとんどのプロトコルは、特定のクラスに関連付けられていない関連メソッドをグループ化します。このタイプのプロトコルは、プロトコルがクラスと混同されないように名前を付ける必要があります。一般的な規則は、動名詞(「... ing」)形式を使用することです。

    NSLocking- 良い。
    NSLock–悪い(クラスの名前のようです)。

  • 一部のプロトコルでは、いくつかの別個の小さなプロトコルを作成するのではなく、多数の無関係なメソッドをグループ化します。これらのプロトコルは、プロトコルの主要な表現であるクラスに関連付けられる傾向があります。これらの場合、規約はプロトコルにクラスと同じ名前を付けることです。

    この種のプロトコルの例は、NSObjectプロトコルです。このプロトコルは、クラス階層内でのオブジェクトの位置に関するオブジェクトのクエリ、特定のメソッドの呼び出し、および参照カウントのインクリメントまたはデクリメントに使用できるメソッドをグループ化します。NSObjectクラスはこれらのメソッドの主要な表現を提供するため、プロトコルはクラスにちなんで命名されます。

ただし、2番目のポイントのアドバイスは適用されなくなりました。

クラスとプロトコルの名前空間はSwiftで統一されているNSObjectため、Objective-CのプロトコルはSwiftで再マッピングさNSObjectProtocolれます。(ソース

ここでは…Protocol、プロトコルをクラスから明確にするためにサフィックスが使用されました。

スウィフト標準ライブラリのプロトコルが含まれているEquatableComparablePrintable。これらはCocoaの「…ing」形式ではなく、「…able」サフィックスを使用して、このタイプのインスタンスが特定の操作をサポートする必要があることを宣言します。


結論

プロトコルに関連する実装が1つしかないいくつかのケースでは、クラスとプロトコルが同じ名前を持つことができるように、「…Protocol」サフィックスが意味をなすことがあります。ただし、これはそのような場合にのみ制限する必要があります。

それ以外の場合、名前はこのプロトコルに含まれる操作を反映する名詞にする必要があります。「…ing」または「…able」形式の動詞を使用することは出発点として適切であり、そのような名前はクラス名と競合する可能性は低いです。

名前EquatableProtocolお勧めできません。名前EquatableまたはEquatingはるかに良いだろう、と私はすべてのクラスが名前を持つことを期待しないでくださいEquatable。この場合、Protocol接尾辞はノイズです。


6
FooDelegateも一般的です(少なくとも、ほとんど常にプロトコルであるデリゲートの場合...実際には常に)
ストライプ

3
Swift API設計ガイドラインごと:swift.org/documentation/api-design-guidelines >>何かが名詞として読まれるべきかを説明するプロトコル(例:コレクション)。>>機能を記述するプロトコルは、サフィックスのable、ible、またはingを使用して命名する必要があります(例:Equatable、ProgressReporting)。
デビッドジェームズ

1
@amonクラスBluetoothServiceまたはUserDataManagerのプロトコルにどのように名前を付ける必要がありますか?「... ing」または「... able」はここに収まりません。「Protocol」という接尾辞は避けたいのですが、何か考えはありますか?Api設計ガイドラインによると、この場合、プロトコルはBluetoothServiceのような名詞である必要がありますが、その場合はどの名前を実装する必要がありますか?BluetoothServiceImpl?ところで 私が見た多くの例の後、C#にはIAnything、IEquatable、ISmthAwareのような「I」プレフィックスを持つ最高の変換があると思います:D
Wojciech Kulik

1
@WojciechKulikあなたの場合、どんな名前がいいのかわかりません。多くは、それらのプロトコルがどのように使用されるかに依存します。ただし、…Serviceおよび…Managerの名前は一種のコードの匂いになる可能性があります。その接尾辞を削除した場合、名前は基本的に同じです。考慮すべきいくつかの名前:Bluetooth、BluetoothConnecting、BluetoothProtocol、UserData、UserDataRepository、UserDataWriting、UserDataProtocol。
アモン

1
@DeclanMcKennaの命名は非常に主観的なものになる可能性があり、どの名前を選択するかは必ずしも明らかではありません。ただし、多くの場合、プロトコルを使用して、厳密にスコープされた機能を表現する必要があります(インターフェイス分離の原則も比較してください)。
amon
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.