インターフェイスの命名規則
これはもちろん主観的なものですが、インターフェース名の前に「I」を付けることには何のプラスもありません。私にとって、Thingは実際には常にIThingより読みやすくなっています。
私の質問は、なぜこの条約がなぜ存在するのですか？確かに、他のタイプのインターフェースと区別しやすくなります。しかし、その議論はハンガリーの表記法を維持することにまで及んでいませんか？
その厄介な「私」に対するあなたの主張は何ですか？または、さらに重要なこととして、Microsoftは何である可能性がありますか？
条約（およびそれらに対する批判）にはすべて背後に理由があるので、条約の背後にあるいくつかの理由を詳しく見てみましょう
インターフェースの種類を実装から区別するために、インターフェースには接頭辞が付けられます-たとえば、上記のように、
ThingとそのインターフェースIThingを簡単に区別する方法が必要ですしたがって、この条約はこの目的を果たすためのものです。インターフェイスには、抽象クラスと区別するためにプレフィックスIが付けられています-次のコードを表示すると、あいまいになります。
public class Apple: Fruit規則がないと、
AppleがFruitという名前の別のクラスからinheritingであるかどうか、またはFruitという名前のインターフェイスのimplementationであるかどうかはわかりませんが、IFruitはこれを明らかにします：public class Apple: IFruit最小の驚きの原則が適用されます。
ハンガリー語表記のすべての使用が非難されるわけではありません-ハンガリー語表記の初期の使用は、オブジェクトのタイプを示す接頭辞を示し、その後に変数名または変数名の前に下線が付いていることがあります。これは、特定のプログラミング環境（Visual Basic 4〜6など）では有用でしたが、真のオブジェクト指向プログラミングの人気が高まるにつれて、型を指定することは非現実的で冗長になります。これは、インテリセンスに関しては特に問題になりました。
今日のハンガリー語表記は、UI要素を実際のデータおよび同様に関連付けられたUI要素から区別するために許容されます。たとえば、テキストボックスの
txtObject、テキストボックスに関連付けられているラベルのlblObject、テキストボックスのデータは単にObjectです。また、ハンガリー語表記の元々の使用は、データ型（システムハンガリー表記）の指定ではなく、変数名（アプリハンガリー表記）の意味的使用の指定ではなかったことも指摘する必要があります。詳しくは ハンガリー語表記のウィキペディアエントリ を参照してください。
私がそれをする理由は簡単です。それが慣習だからです。私はすべてのコードを異なるように見せるのではなく、単にそれに従い、読みにくく、学習しにくくしたいと思います。
まあ、1つの明白な考慮事項は（非常に一般的な）IFooとFooのペア（Fooを抽象化する場合）ですが、より一般的には、何かがインターフェイス対クラス。はい、それは部分的に冗長ですが、IMOはsCustomerNameのようなものとは異なります-ここでは、名前自体（customerName）で変数を理解するのに十分です。
しかし、CustomerRepositoryの場合-それはクラスですか、それとも抽象インターフェースですか？
また、期待;事実は、正しいか間違っているか、それは人々が期待することです。それはほぼ十分な理由です。
ThingはIThingより読みやすい名前です。私は、特定の実装ではなく、インターフェイスにプログラムする必要があると考えている学校です。したがって、一般的に言えば、インターフェースは実装よりも優先されるべきです。実装よりも読みやすい名前をインターフェースに付けることを好みます（つまり、インターフェースには「I」接頭辞なしで名前が付けられます）。
あなたの質問は、.NET Frameworkとその標準に取り組んだMicrosoftチーム内での多くの長い議論のトピックだったと思います。
最もわかりやすい例はソース自体からのものだと思います。以下に、私が強くお勧めする本 Framework Design Guidelines からの抜粋を転記します。
CLRプログラムマネージャーであるKrzysztof Cwalinaから：
使用される唯一の接頭辞は、インターフェースの「I」です（
ICollectionなど）。ただし、これは歴史的な理由によるものです。振り返ってみると、通常の型名を使用するほうがよかったと思います。ほとんどの場合、開発者は、たとえば、何かがインターフェースであり、抽象クラスではないことを気にしません。
Brad Abrams、CLRおよび.NET Frameworkプログラムマネージャーから：
一方、インターフェイスの「I」プレフィックスは、.NET Frameworkに対するCOM（およびJava）の影響を明確に認識したものです。 COMが普及し、制度化された場合でも、インターフェイスの表記は「I」で始まります。この歴史的なパターンからの逸脱について説明しましたが、多くのユーザーが既にCOMに精通しているため、パターンを引き継ぐことにしました。
コンサルタント兼著者のJeffrey Richterから：
個人的には、「I」という接頭辞が好きで、このようなものがもっとあればよいのですが。 1文字の小さな接頭辞は、コードを簡潔にしつつ説明的にするのに役立ちます。 [...]プライベートタイプのフィールドにはプレフィックスを使用しています。これは非常に便利だからです。
私のポイントは、それはディスカッションテーブルにあった。私が見る利点は、それがクラスとインターフェースの間の名前の衝突を回避するのに役立つので、あなたの名前は説明的でコンパクトなものになることができるということです
個人的に、そしておそらく習慣から、私はI接頭辞が好きです。インターフェイスにフラグを付けると、実装型と1対1で名前が対応できるからです。これは、base実装を提供する場合に役立ちます。IThingはインターフェース、Thingは基本（おそらくabstract）タイプです。派生型はSomeThingにすることができます。私はそのような非常に明確な省略表記を使用できることが大好きです。
具体的なクラスに "Impl"サフィックスを追加するよりも良いと思います。それは単一の手紙であり、この慣習は確立されています。もちろん、好きな名前を自由に使用できます。
インターフェースにI規約を使用しないことには何の問題もありません。一貫性を保ち、それが自分だけでなくチーム全体（存在する場合）でも機能することを確認してください。
私の意見では、この「私」は単なる視覚的なノイズです。 IDEはクラス名とインターフェース名を異なる方法で表示する必要があります。幸いなことにJava標準ライブラリはこの規則を使用しません。
あなたは通常IThing and a Thingを持っているからです。そのため、この繰り返し発生する状況に対応するための独自の「規則」を用意する代わりに、すべての規則に1つのサイズで統一されたものが選択されました。他の人の言うことを反省して、事実上の標準性はそれを使用するのに十分な理由です。
ガイドラインではなぜプレフィックスIを使用する必要があるかについて説明されていませんが、これが現在確立された規則であるという事実が理由であるべきです足りる。
I接頭辞を削除することで何を得る必要がありますか？
インターフェイスに名前を付けることは、名前の前に「I」を付けるかどうかだけではなく、より深い意味を持つ必要があります。
「フルーツ」も「IFruit」も、インターフェースとして私にとってはそれほど意味がありません。これは、クラスのように見えるからです。クラスは物事を定義しますが、インターフェースは機能を定義する必要があります。
「I」という命名規則は、クラスとインターフェースを区別するのに役立ちますので、開発が少し簡単になります。また、必須ではありませんが、オブジェクト指向の一般的なコーディングの問題を回避するのに役立ちます。 C＃は、Javaと同様に、単一の基本クラスからの継承のみを許可します。ただし、必要な数のインターフェイスを実装できます。注意点は、クラスから継承して1つ以上のインターフェースを実装する場合、基本クラスを最初に指定する必要があることです（つまり、クラスTrout：Fish、ISwimmer、IDiver ...）。
私は、インターフェイスの名前と、それらが提供する機能と、インターフェイスの種類（つまり、アニメーションインターフェイスまたは無生物インターフェイス）に基づいて名前を付けたいと思っています。
インターフェースが提供する機能に重点を置くと、インターフェースの名前をすばやく判別できます。また、インターフェイスが無関係な関数を定義しているかどうかをすばやく確認するのにも役立ちます。
無生物オブジェクト（つまり、それ自体では動作できないもの）を定義するインターフェース...最後に... ableで名前を付けたいIPrintable（Document、Invoiceなど）IPlayable（Instrument、MediaPlayerなど）ISavable （ドキュメント、画像など）IEdible（果物、牛肉など）IDrivable（車など）IFlyable（飛行機など）
アニメーションオブジェクトを定義するインターフェイス（つまり、独自に動作するもの）...最後に... erという名前を付けたいISwimer（Fish、Dog、Duckなど）IDiver（Fish、Duckなど）IFlyer（ Pilotなど）IDriver（NascarDriverなど）
結局、「I」という命名規則は、インターフェースとクラスを区別するのに役立ちます。ただし、最初に「I」だけでなく、追加の命名ロジックを追加することは意味があります。
名前の衝突を防ぐことを意図しているのは単なる規則です。 C＃では、ファイル名がそれぞれClientとIClientであっても、Clientという名前のクラスとインターフェイスを使用できません。私は慣習を使用して快適です。別の規則を提供する必要がある場合は、「契約」をサフィックスとして使用することをお勧めします。 ClientContract。
彼らがその慣習を選んだ理由は正確にはわかりません。おそらく、「I am Enumerable」のように、クラスの一部に「I」を吹き込むことを考えているのかもしれません。
フレームワークの残りの部分でより詳細になる命名規則は、名前にタイプを組み込むことです。たとえば、xxxAttributeおよびxxxExceptionクラスをxxxInterfaceにします。ただし、これは少し時間がかかります。結局のところ、インターフェースは、クラスの別の束ではなく、何か別のものです。
インターフェイスをクラスから分離するため。
また、（これは、高から指示されたものよりも個人的な観察です）、インターフェイスはクラスが何をするかを記述します。 「私」はこれに向いています（これは、今すぐ書き出すのに最適な文法の構成要素だと確信しています）。検証するクラスを記述するインターフェイスは「IValidate」になります。マッチング動作を説明するものは「IMatch」です。
見た目は ハンガリー語 気分がいい。ハンガリー語は一般に、強く型付けされた言語の脅威と見なされています。
C＃はMicrosoft製品であり、ハンガリー語表記はMicrosoftの発明であったため、C＃がその影響を受けやすい場所を確認できます。
Microsoftのガイドラインでは、「I」を使用してインターフェイスとして説明することを推奨していることを知っています。しかし、これは、覚えていなければIBMの命名規則に由来します。インターフェースには「I」が始まり、実装には* Implが続きます。
ただし、私の意見では、Java命名規則は、IBMの命名規則よりも優れた選択肢です（Javaだけでなく、C＃やその他のOOプログラミング言語。インターフェースは、オブジェクトがインターフェースを実装する場合にオブジェクトが実行できることを説明し、説明は動詞形式でなければなりません。つまり、実行可能、シリアル化可能、請求可能などです。これは、インターフェースが表すものの完全な説明です。
OS GUIがファイルとフォルダーに異なるアイコンを使用することは人気があります。それらすべてが同じアイコンを共有しているが、フォルダの先頭に「F」が付いている場合、同じアイコンを使用することは許容されます。ただし、人間の画像認識速度はWordの認識速度よりも速いため、アイコンを使用しています。
IDEのようなコンピュータプログラムは、ファイルのインターフェース性を明確にすることができます。これにより、同じ名前で発生するさまざまなレベルの抽象化の名前空間が解放されます。例えば。 「ICare」の「I」は実装を示し、「Care」はインターフェースの機能を示します。
「I」のコンベンションは、これ以上考えることができなかったのでとても人気があると思いますが、この種の情報を知る必要があることを指摘しているので、存在は重要です。
問題の事実は、誰もがそれを理解し、より良いコードを書くことの一部が読みやすく理解しやすいことです。
「SerializerInterface」などのカスタマイズされたインターフェイスに、「Interface」という単語をサフィックスとして追加できます。抽象クラスの場合、「Fruit」、たとえば「FruitAbstract」、または「AbstractFruit」にすることができます。十分に読みやすいか、通常の命名規則に従ってください。
ちょうど私の2セント：
私が個人的にサフィックス「インターフェース」を追加する理由は、「I」プレフィックスよりも読みやすく、システム内のファイルが「グループ化」されてリストされているためです。例えば：
そんなに良くない：
Alien.php
Host.php
IAlien.php
IHost.php
IXenomorph.php
Xenomorph.php
より良い：
Alien.php
AlienInterface.php
Host.php
HostInterface.php
Xenomorph.php
XenomorphInterface.php
しかし、それは単なる個人的な好みです。プロジェクト全体で一貫した命名規則を使用している限り、独自の命名規則を使用することに抵抗はありません。
私はこの慣習があまり好きではありません。同じ名前のインターフェイスと実装がある場合に役立つことを理解していますが、見苦しいだけです。もちろん、それが私が働いているコンベンションであるなら、私はまだそれに従います。一貫性は規約のポイントであり、一貫性は非常に良いことです。
Validatorのように、できるだけ一般的な方法でインターフェイスの機能を説明するインターフェイスを用意します。特定のものを検証する特定の実装はThingValidatorであり、Validatorsによって共有されるいくつかの抽象的な機能を持つ実装はAbstractValidatorです。 Thingが唯一の...まあ...私が検証していることであり、Validatorがジェネリックであっても、これを行います。
インターフェースに対して1つの具象クラスだけが理にかなっている場合でも、名前の衝突を防ぐためにインターフェースに別の名前を付けるのではなく、その特定の実装に固有の何かを記述しようとします。結局のところ、実装の名前よりもインターフェイスの名前を頻繁に入力することになります。