インターフェイス名は「I」プレフィックスで始まる必要がありますか？

私は、ロバート・マーティンによる「クリーン・コード」を読んで、できればより良いプログラマーになることを望んでいます。これまでのところ、どれも本当に画期的なものではありませんでしたが、アプリケーションの設計とコードの記述方法について、私は違った考え方をしました。

本の一部には、同意しないだけでなく、特にインターフェースの命名規則に関して、私には意味がありません。これは、本から直接取ったテキストです。混乱を招くと思われるこの側面を太字で示し、説明を希望します。

私はインターフェースを装飾しないままにしておきたい。前のIは、今日のレガシーワッドで非常に一般的であるが、せいぜい気を散らすものであり、最悪の場合には情報が多すぎる。ユーザーにインターフェースを渡していることをユーザーに知らせたくない。

おそらく、私が学生だからか、プロやチームベースのプログラミングを一度もしたことがないからかもしれませんが、それがインターフェースであることをユーザーに知ってもらいたいからでしょう。 インターフェイスの実装とクラスの拡張には大きな違いがあります。

それで、私の質問は、「コードの一部がインターフェースを期待しているという事実を隠す必要があるのか​​？」に要約されます。

編集

回答に応じて：

タイプがインターフェースである場合、またはクラスがあなたのビジネスであり、コードを使用している誰かのビジネスではない場合。したがって、このサードパーティのコードでコードの詳細を漏らさないでください。

特定の型がインターフェイスであるか、サードパーティのコードのクラスであるかの詳細を「漏洩」しないのはなぜですか？サードパーティの開発者がコードを使用して、インターフェイスを実装するのか、クラスを拡張するのかを知ることは重要ではありませんか？違いは、私が自分の頭に浮かぶほど重要ではありませんか？

それについて考えるのをやめた場合、インターフェイスは実際には抽象クラスと意味的にそれほど変わらないことがわかります。

• 両方ともメソッドおよび/またはプロパティ（動作）があります。
• どちらにも非プライベートフィールド（データ）がありません。
• どちらも直接インスタンス化することはできません。
• 1つから派生するとは、派生型も抽象でない限り、その抽象メソッドを実装することを意味します。

実際、クラスとインターフェイスの最も重要な違いは次のとおりです。

• インターフェイスにプライベートデータを含めることはできません。
• インターフェイスメンバはアクセス修飾子を持つことができません（すべてのメンバは「パブリック」です）。
• クラスは複数のインターフェイスを実装できます（通常、1つの基本クラスのみから継承できるのに対して）。

クラスとインターフェースの唯一の特に意味のある違いは、（a）プライベートデータと（b）タイプ階層（どちらも呼び出し側にわずかな違いももたらさない）を中心に展開するため、通常、タイプがインターフェースであるか、クラス。もちろん、視覚的な表示は必要ありません。

ただし、注意すべき特定のコーナーケースがあります。特に、リフレクション、インターセプト、ダイナミックプロキシ/ミックスイン、バイトコードウィービング、コード生成、または環境のタイピングシステムまたはコード自体を直接操作することを伴うものを使用している場合は、すぐに知ることが非常に役立ち、時には必要ですインターフェースを扱うのかクラスを扱うのかに関係なく。インターフェースではなくクラスをミックスインとして追加しようとしたため、コードが不可解に失敗することは明らかに望ましくありません。

ただし、一般的な、バニラで、すぐに使えるビジネスロジックコードの場合、抽象クラスとインターフェイスの違いは、決して機能しないため、宣伝する必要はありません。

Iとにかく、Microsoftが使用および提唱している.NET規則であるため、とにかくC＃インターフェイスのプレフィックスを付ける傾向があります。そして、新しい開発者にコーディング規則を説明するとき、Microsoftの規則を使用するだけで、独自の「特別な」規則がある理由を説明するよりもはるかに簡単です。

多くの点で、一貫性は慣例よりも重要です。命名スキームが一貫している限り、それらを扱うのは難しくありません。必要に応じてプレフィックスIを使用するか、名前をそのままにしておくか、スタイルを選択してそれを使用する限り、それは重要ではありません。

この本は良いものでいっぱいですが、インターフェイス名に「I」を追加します。

public interface ILogデフォルトの実装を使用していると想像してくださいpublic class Log。

さて、持っていると決めたらpublic interface Log、突然Logクラスをpublic class LogDefaultそれらの行に変更する必要があります。キャラクターを1つ追加することから7つに変更しました-確かに無駄です。

多くの場合、理論と実践の間には細かい境界線があります。理論的にはこれは非常に良い考えですが、実際にはあまり良くありません。

これは、インターフェイスの実装やクラスの拡張に関するものではありません。それらの場合、とにかくあなたは何をしているのかを知っています。

ただし、サードパーティコード（exempleのアプリケーションの別のモジュール）がデータを操作する場合、このコードは、インターフェイスまたはクラスを提示するかどうかを気にする必要はありません。

これが抽象化のポイントです。このサードパーティコードに、特定のタイプのオブジェクトを提示しています。この型には、呼び出すことができるメンバー関数があります。それで十分です。

タイプがインターフェースである場合、またはクラスがあなたのビジネスであり、コードを使用している誰かのビジネスではない場合。したがって、コードの詳細をこのサードパーティのコードに漏らさないでください。

ちなみに、インターフェイスとクラスは最後に参照型になります。そして、これが重要なことです。したがって、これが命名規則で強調する必要があるものです。

ほとんどの答えは、プログラミング言語がJavaまたはC＃であり、インターフェイス/抽象クラスの概念（またはキーワード）があると仮定しているようです。これらの場合、まともなIDEでは、どのタイプのクラス1が対処するのかがすぐにわかり、書き込みpublic interface IMyClassは不必要な複製です。あなたが書かないようなものですpublic final FinalMyClass-クラス名にすべてのキーワードを入れることを想像してください。

ただし、C ++での私の意見では、状況は少し異なります。ヘッダーファイルに飛び込んで、クラスに抽象クラスかどうかを確認する仮想メソッドがあるかどうかを確認する必要があるためです。その場合、私は書くことについての議論を明確に見ることができclass AbstractMyClassます。

私の答えは、プログラミング言語に依存します。

2016年更新： 2年後のC ++の経験おそらくクラス名の前にを付けるのは悪い習慣Abstractだと思いますが、おそらく理にかなっているほど複雑なコードベースがあると思います。

使用している言語のイディオムに従ってください。

各言語には独自のイディオムとコーディングガイドラインがあります。たとえば、C＃では、インターフェイスの先頭にIを付けるのが慣用的です。Goでは、そうではありません。

私の（Java）コードでは、呼び出し元に公開するAPIでこの規則を使用する傾向があります。

• 機能はインターフェースを通じて提供され、クラスによって提供されることはありません。
• 非機能部分はクラスです。

機能しないということは、純粋なデータ構造（XMLシリアル化またはORMへのブリッジとして機能するクラスなど）、列挙、例外などを意味します。これらはすべてインターフェイスにはなれません（まあ、純粋なデータクラスには、ただし、データを保持する以外にこれらのクラスが行うことはないため、非常にわずかな利益で多くの作業が行われます）。

命名規則の観点から、インターフェースはアクター名詞（例FooBarWatcher）または形容詞（例）にマップする傾向がFooBarWatchableあり、純粋なデータクラスと列挙の両方が非アクティブ名詞（例FooBarStatus）にマップされます。IDEは、特別な命名規則なしでAPIコンシューマーをガイドできます。例外は、（通常のJavaの規則に従ってくださいFooBarException、FooBarError、FooBarFaultもちろん）。

また、自分のルールを破ろうとしないようにするために、インターフェイスを独自のパッケージまたは独自のライブラリに入れることもよくあります。（これは、WSDLドキュメントなどの外部ソースからコードを導出するときに、ビルドを管理するのにも役立ちます。）