命名の問題：「ISomething」の名前を「Something」に変更する必要がありますか？[閉まっている]

Clean Codeの名前に関するボブおじさんの章では、主にハンガリーの表記法に関して、名前のエンコーディングを避けることを推奨しています。またI、インターフェイスからプレフィックスを削除することについて具体的に言及していますが、この例は示していません。

以下を想定してみましょう：

• インターフェイスの使用法は、主に依存性注入によりテスト容易性を実現することです
• 多くの場合、これは単一の実装者と単一のインターフェースを持つことにつながります

それで、例えば、これらの2つは何と命名されるべきでしょうか？ParserそしてConcreteParser？ParserそしてParserImplementation？

public interface IParser {
    string Parse(string content);
    string Parse(FileInfo path);
}

public class Parser : IParser {
     // Implementations
}

または、このような単一実装の場合、この提案を無視する必要がありますか？

「ボブおじさん」を含む多くの人は、Iインターフェースの接頭辞として使用しないことを勧めていますが、そうすることは、C＃で確立された伝統です。一般的には、避けるべきです。しかし、C＃を作成している場合は、その言語の規則に従って実際に使用する必要があります。そうしないと、コードを読み取ろうとするC＃に精通している他のユーザーとの間に大きな混乱が生じます。

インターフェイスは重要な論理概念であるため、インターフェイスには一般的な名前を付ける必要があります。だから、私はむしろ持っている

interface Something
class DefaultSomething : Something
class MockSomething : Something

より

interface ISomething
class Something : ISomething
class MockSomething : ISomething

後者にはいくつかの問題があります。

1. 何かはISomethingの1つの実装にすぎませんが、それは何らかの名前で特別なものであるかのように、一般的な名前を持つものです。
2. MockSomethingはSomethingから派生しているようですが、ISomethingを実装しています。MockISomethingという名前にする必要があるかもしれませんが、実際に見たことはありません。
3. リファクタリングはより困難です。現在何かがクラスであり、インターフェースを導入する必要があることが後でわかる場合は、タイプが具象クラス、抽象クラス、またはインターフェースであるかどうかをクライアントに対して透過的にする必要があるため、そのインターフェースに同じ名前を付ける必要があります。何かがそれを壊します。

これは命名規則だけではありません。C＃は多重継承をサポートしていないため、基本的なクラスから継承して1つ以上のインターフェイスを実装する場合、ハンガリーの表記法のこの従来の使用はわずかながら有用な利点があります。したがって、この...

class Foo : BarB, IBarA
{
    // Better...
}

...これが望ましい...

class Foo : BarB, BarA
{
    // Dafuq?
}

IMO

ダメダメダメ。

命名規則は、ボブおじさんのファンダムの機能ではありません。これらは、c＃などの言語の機能ではありません。

それらはコードベースの機能です。あなたの店のはるかに少ない範囲に。言い換えれば、コードベースの最初のものが標準を設定します。

そうしてはじめて、あなたは決断を下すことができます。その後、一貫性を保ってください。誰かが一貫性を失い始めたら、彼らのナーフガンを取り去り、悔い改めるまでドキュメントを更新させます。

I接頭辞が表示されない場合に新しいコードベースを読み取るときに、言語に関係なく問題ありません。すべてのインターフェイスで表示される場合は問題ありません。時々見かけたら、誰かが支払います。

あなたのコードベースにこの前例を設定するという希少なコンテキストに自分自身を見つけたなら、私はあなたにこれを考慮することを勧めます：

クライアントクラスとして、私は私が話していることを気にしない権利を留保します。必要なのは、名前と、その名前に対して呼び出すことができるもののリストだけです。私がそう言わない限り、それらは変わらないかもしれません。私はその部分を所有しています。インターフェイスするかどうかにかかわらず、私が話しているのは私の部署ではありません。

あなたがIその名前でこっそりした場合、クライアントは気にしません。がないI場合、クライアントは気にしません。話していることは具体的かもしれません。そうではないかもしれません。newどちらの方法でも呼び出さないため、違いはありません。クライアントとして、私は知りません。知りたくありません。

Javaでさえ、そのコードを見ているコードモンキーとして、これは重要かもしれません。結局、実装をインターフェイスに変更する必要がある場合、クライアントに通知せずにそれを行うことができます。I伝統がない場合は、名前を変更することもできません。ソースがバイナリを気にしなくてもクライアントを再コンパイルする必要があるため、これは問題になる可能性があります。名前を変更したことがない場合、見落としやすいもの。

たぶんそれはあなたにとって問題ではないでしょう。そうでないかもしれない。もしそうなら、それは気にする正当な理由です。しかし、机のおもちゃの愛のために、私たちは盲目的にこれを行うべきだと主張しないでください。正当な理由があるか気にしないかのどちらかです。

それと永遠に生きることではありません。どこでも「問題」を修正する準備ができていない限り、コードベースが特定のメンタリティに適合していないことを私にばかげたことはありません。正当な理由がない限り、私は均一性への抵抗が最も少ない道を進むべきではありません。私にはもっと良いことがあります。

ここで重要なのは、JavaとC＃の小さな違いの1つです。Javaでは、すべてのメンバーはデフォルトで仮想です。C＃では、すべてのメンバーはデフォルトでシールされます-インターフェイスメンバーを除きます。

これに伴う仮定はガイドラインに影響します。Javaでは、リスコフの置換原則[1]に従って、すべてのパブリックタイプを非最終と見なす必要があります。実装が1つしかない場合は、クラスに名前を付けますParser。複数の実装が必要な場合は、クラスを同じ名前のインターフェイスに変更し、具体的な実装をわかりやすい名前に変更します。

C＃では、クラスを取得するとき（名前がで始まらないI）、それが目的のクラスであるという主な仮定です。念のため、これは100％近い精度ではありません-典型的な反例はStream（実際にはインターフェイスまたはいくつかのインターフェイスであるはずの）クラスであり、誰もが他の言語からの独自のガイドラインと背景を持っています。かなり広く使われているような他の例外もありますBase抽象クラスを意味する接尾辞は-ちょうどインタフェースと同じように、あなたが知っているタイプが多型であることを想定しています。

インターフェイスを抽象クラスにすることに頼ることなく、そのインターフェイスに関連する機能の非接頭辞付きの名前を残す便利な機能もあります（C＃にはクラスの多重継承がないために傷つきます）。これはIEnumerable<T>、インターフェイスEnumerableとして、およびそのインターフェイスに適用されるメソッドのリポジトリとして使用するLINQによって普及しました。これは、インターフェイスにメソッド実装を含めることができるJavaでは不要です。

最終的に、IプレフィックスはC＃の世界で広く使用され、拡張により、.NETの世界（.NETコードのほとんどがC＃で記述されているため、ほとんどのパブリックインターフェイスでC＃のガイドラインに従うことが理にかなっています）。これは、この表記法に従うライブラリとコードをほぼ確実に使用することを意味し、不要な混乱を防ぐために伝統を採用することは理にかなっています-プレフィックスを省略するとコードが良くなるというわけではありません:)

ボブおじさんの推論は次のようなものだったと思います。

IBananaバナナの抽象的な概念です。実装クラスの名前がの場合よりも優れている可能性がある場合Banana、抽象化はまったく意味がないため、インターフェイスを削除してクラスを使用する必要があります。より良い名前（たとえば、LongBananaまたはAppleBanana）がある場合Banana、インターフェイスの名前として使用しない理由はありません。したがって、Iプレフィックスを使用することは、無駄な抽象化があることを意味します。これにより、コードが理解しにくくなり、メリットがありません。また、厳密なOOPを使用すると、常にインターフェイスに対してコードIが作成されるため、型のプレフィックスが表示されない唯一の場所は、コンストラクターになります-非常に無意味なノイズです。

これをサンプルIParserインターフェイスに適用すると、抽象化が完全に「意味のない」領域にあることが明確にわかります。どちらのパーサ（例えばの具体的な実装についての具体的な何かがあるのですJsonParser、XmlParser、...）、またはあなただけのクラスを使用する必要がありますが。特定の実装がある場合、または「デフォルト」の抽象クラスまたは拡張メソッドが必要な場合は、「デフォルト実装」（一部の環境ではこれが実際に意味をなしますが、特にCOM）はありません。ただし、C＃では、コードベースで既に-prefixが省略されていない限りI、そのままにしてください。次のようなコードが表示されるたびにメンタルノートを作成するだけです。class Something: ISomethingつまり、誰かがYAGNIをフォローし、合理的な抽象化を構築するのが得意ではないということです。

[1]-技術的には、これはリスコフの論文では特に言及されていませんが、元のOOP論文の基礎の1つであり、リスコフの私の読書では、彼女はこれに挑戦しませんでした。それほど厳密ではない解釈（ほとんどのOOP言語で採用されている解釈）では、これは、置換（つまり、非最終/密閉）を目的とするパブリック型を使用するコードは、その型の準拠実装で動作する必要があることを意味します。

それで、例えば、これらの2つは何と命名されるべきでしょうか？パーサーとコンクリートパーサー？パーサーとParserImplementation？

理想的な世界では、名前の前に略記（「I ...」）を付けるのではなく、名前に概念を表現させてください。

このISomethingの規則は、「Dollar」クラスが必要なときに「IDollar」概念を定義するように導くという意見をどこかで読んでいますが、正しい解決策は単に「通貨」と呼ばれる概念です。

言い換えれば、規約は物事の命名の難しさにイージーアウトを与え、イージーアウトは微妙に間違っています。

現実の世界では、コードのクライアント（「未来からのあなた」かもしれません）は、後でそれを読み、できるだけ早く（または少しの労力で）慣れる必要があります（クライアントに与える）あなたのコードの彼らが得るものを期待しています）。

ISomething規約では、悪名/悪名を紹介しています。とは言っても、コードを書く際に使用されている慣習や慣行がもはや実際的でない限り、クラフは実際のクラフではありません*）。規約に「ISomethingを使用する」と書かれている場合は、他の開発者に適合させる（そしてより良く動作させる）ために使用するのが最善です。

*）「cruft」はとにかく正確な概念ではないため、このことを言っても大丈夫です:)

他の回答が言及しているように、インターフェイス名の接頭辞Iは.NETフレームワークのコーディングガイドラインの一部です。具象クラスはC＃やVB.NETのジェネリックインターフェイスよりも頻繁にやり取りされるため、命名スキームのファーストクラスであり、したがって、IParserインターフェイスとParserデフォルト実装の最も単純な名前を使用する必要があります。

しかし、Javaや同様の言語の場合、具体的なクラスの代わりにインターフェイスが優先されるため、ボブおじさんはI削除する必要があり、インターフェイスは最も簡単な名前（Parserたとえば、パーサーインターフェイス）を持つ必要があります。ただしParserDefault、のようなロールベースの名前の代わりに、クラスにはパーサーの実装方法を説明する名前が必要です。

public interface Parser{
}

public class RegexParser implements Parser {
    // parses using regular expressions
}

public class RecursiveParser implements Parser {
    // parses using a recursive call structure
}

public class MockParser implements Parser {
    // BSes the parsing methods so you can get your tests working
}

これはどのように、例えば、あるSet<T>、HashSet<T>とTreeSet<T>命名されています。

このI =インターフェイスの規則が（新しい）規則を破るという点で正しい

昔は、すべてをその型intCounter boolFlagなどでプレフィックスしていました。

プレフィックスなしで名前を付けたいが、「ConcreteParser」も避けたい場合は、名前空間を使用できます

namespace myapp.Interfaces
{
    public interface Parser {...
}


namespace myapp.Parsers
{
    public class Parser : myapp.Interfaces.Parser {...
}