インターフェースの命名：接頭辞「Can-」と接尾辞「-Able」

インターフェイスのサフィックスとして「-able」を使用するのが一般的です

Serializable Printable Enumerable Drinkable Shootable Rotatable

「Can-」の方がわかりやすいので、もっと良いかもしれないと考えていました。はい、より冗長であり、インターフェイス名にノイズを追加します。特に、受動動詞を使用できます。

例えば、Shootableは、オブジェクトが射撃できることを意味します（銃がこれを実装する場合があります）、または射撃できることを意味します（ターゲットボードがこれを実装する場合があります）。「Can-」プレフィックスを使用すると、前者は「CanShoot」になり、後者は「CanBeShotAt」または「CanShootAt」になります。

例2ドキュメント「CanBePrinted」とプリンター「CanPrint」

または、「-Able」に固執し、ドキュメントにコンテキストを提供させますか？

ご意見。

おそらく、Is-ableが必要ですか？

.Netのいくつかの例：

NetworkStream.Readable
NetworkStream.Writable
Stream.CanRead
Stream.CanWrite
Type.IsSerializable

統一された標準はないようです。読みやすいものを選択してください。

if (document.IsPrintable && printer.CanPrint) { printer.Print(document) }

編集：指摘したように、質問はプロパティではなくインターフェイスに関するものでした。

その場合、Can-という名前のインターフェイスは見つかりません。インターフェイスは常に-ableを使用する傾向があります。この用語に同意します。メソッドは、パラメータa ISerializable objectまたはとしてリクエストできますIPrintable document。a ICanBeSerialized objectまたはa を要求するのICanBePrinted documentは読むのがとても厄介です。

反対側のプリンターでは、単にインターフェイスを呼び出すことをお勧めしますIPrinter。メソッドはを要求しますIPrinter device。

以下のメソッドシグネチャを声に出して読んでください。（個人的には、「I」プレフィックスはサイレントであると考えています。）読みやすいですか？正しく聞こえますか？

void PrintDocument(IPrinter device, IPrintable document)
{
    device.Print(document)
}

文法的に言えば、「canFoobar」は述語で、「Foobarable」は形容詞または名詞（通常、APIのコンテキストでは名詞）です。

また、微妙な違いにも注意してください。-ableは、適用される名詞の受動的な役割を意味します。can-はアクティブな役割を意味します。つまり、Something canFoobarの場合、他の何かをfoobarできます。または、別の角度から：AがBをfoobarできる場合、A.canFoobar()and B is Foobarable。

OOPの表現力の観点では、述語をメソッドまたはプロパティに関連付けますが、名詞はクラスまたはインターフェイスです。そう：

instance.canFoobar();

class Something implements Foobarable { ... }

個人的には-ableバージョンに固執します。私の理由は次のとおりです。ほとんどの（すべて？）グラフィカルエディターは、入力内容に基づいて識別子を提案します。それらのいくつかは識別子内でも検索するのに十分「スマート」ですが、一部はまだ識別子の検索開始を提供するだけです。

入力をスピードアップするには、できるだけ少ないキーストロークで、推奨される識別子のリストを短くしたいです。識別子の先頭が同じであれば、たとえば「ICan-」のように入力する文字が多くなります。

これがあなたのケースで問題ではないと思うなら、それは素晴らしいことであり、命名規則を選択するために他の基準を使用することをお勧めします。私たちのチームの場合など、場合によっては、できるだけ少ないキーストロークで区別する識別子を好みます。

それとは別に、プロジェクトで作業している人にとってコードが最も理解しやすい命名規則を使用することをお勧めします。チーム内で会話しましょう。そのようなものはありません。うまく機能する規則とあまり機能しない規則。

優れたリファクタリングツールを使用すると、好きなだけ名前を変更できることを忘れないでください。そのため、さまざまなアプローチを簡単に試すことができます。

明らかに、接頭辞と接尾辞は、さまざまなタイプのアクション、またはむしろ、アクションのさまざまな方向に対するほとんど明白な選択肢です。

ただし、多くの理由により、現在の使用と設定は一貫していない場合があります。

アクションが実行されることにより、対象物：
CanShoot - > これ芽何か（時）
CanFly - > それはハエ
CanChangeメソッドを- > それは変わります

アクションが実行された上でオブジェクト：
読み取り可能に- > あなたはそれを読むことができる
書き込み可能に- > あなたがそれ（に）書き込むことができます
印刷可能- > あなたはそれを印刷することができます

規則ではなく、必ずしも論理的ではない場合もありますが、規則を採用し、変数の命名における使用の一貫性を維持するのに役立ちます。

機能と許可を区別したいと思うかもしれません。一方でSerializableとCanSerialize何かが連載されることが可能であることを意味し、また、アクセス許可の問題（あるいはディスク・スペースの不足）とあなたが考慮しなければならないことがありありますMaySerialize。で物事を残して~able区別する必要が削除しcanとmay。

インターフェイスをサブクラス化/実装するとき、経験則では「BはAです」（BはAを実装します）と言うことができるはずだと思います。次のように言うのは正しくありません：

A DocumentはCanBePrinted

ただし、次のように言うのは正しい（または少なくともより良い）ように思えます。

A DocumentはPrintable

インターフェイスの名前には文法的にも規約的にもXableの方が適していると思いますが、IsX、CanX、DoesXはプロパティの名前に適しています。

MSDNから：

「肯定的なフレーズ（CantSeekの代わりにCanSeek）を使用してブールプロパティに名前を付けます。オプションで、ブールプロパティに接頭辞Is、Can、またはHasを追加できますが、値を追加する場所のみです。」http://msdn.microsoft.com/en-us/library/ms229012.aspx

私の意見では、「-able」のバリアントは、提案されている「CanDoSomething」よりはるかに読みやすく、はるかに多くのラクダのこぶを押し付けます。

Scalaでは、*Ableインターフェイスに使用されますがCan*、タイプクラスパターンに使用されます。基本的に、特定のメソッドを呼び出すには、特定のタイプの暗黙的な値がスコープ内に存在する必要があります。このタイプの名前には、接頭辞としてCan。