すべてにインターフェースがあります
可能性のある複製：
1つのクラスだけが実装するインターフェースを使用する必要がありますか？
私は、実際のすべてのクラスがインターフェイスを実装しているプロジェクトを引き継ぎます。これらのインターフェースの大部分は、類似した名前とまったく同じメソッドを共有する単一のクラスによって実装されます（例：MyCarおよびMyCarImpl）。プロジェクト内の2つのクラスは、その名前を共有するインターフェース以上のものを実装していません。
一般的な推奨事項は実装ではなくインターフェイスにコーディングすることですが、これでは少しやりすぎませんか？システムは、既存のクラスとよく似た動作をする新しいクラスを追加する方が簡単であるという点で、より柔軟かもしれません。ただし、コードを解析するのは非常に難しく、メソッドの変更には1ではなく2つの編集が必要になりました。
個人的には、通常、複数のクラスが同じ動作をする必要がある場合にのみインターフェースを作成します。私は [〜＃〜] yagni [〜＃〜] をサブスクライブしているので、本当に必要な場合を除き、何かを作成しません。私はそれをすべて間違っていますか、このプロジェクトは行き過ぎですか？
これは [〜＃〜] yagni [〜＃〜] 原則の真っ向からの違反であり、そのようにしないことを強くお勧めします。本当に必要なときに後でインターフェースを導入するのは簡単なので、前もって作成する必要はありません。これはJavaの人々の間では非常に一般的なパターンであると聞きましたが、理由は聞かれません、私にはわかりません。
ただし、これが共同作業の対象となるチームプロジェクトである場合は、確立された基準が悪いとしても、従う必要があります。
これは、プロジェクトに [〜＃〜] solid [〜＃〜] 原則を部分的に適用する場合によくあることであり、必ずしも悪いことではありません。
クラスではなくインターフェイスに対するコーディングは、依存関係の逆転を維持するための合理的な方法であり、テスト可能なソフトウェアコンポーネントを作成するのに非常に便利です（必要だと言う人もいます）。
ただし、システムがすべてのクラスで1つのインターフェースとして正確に、またはその逆の場合、インターフェースの分離を尊重していない可能性が高く、ほぼ間違いなく「You Ai n't Gonna Need It」のガイドラインに違反しています。
各クラスのインターフェースを作成する開発時間（現在および将来）のコストを検討し、より良いインターフェース分離がプロジェクトに利益をもたらすかどうかを評価します。これらの原則とガイドラインは、さまざまな設計のトレードオフを理解し、それらについて効果的に伝達できるようにするためにのみ存在します。従うべき規則とその厳密さの決定はあなたの手に委ねられています。
はい、このプロジェクトは行き過ぎです。これが発生する主な理由は2つあります。
- プログラマーは、実際にメリットが得られる場所と得られない場所を理解せずに、盲目的に一部のドグマをフォローしていました。
- プログラマーはテスト駆動開発を行っており、テスト用のモックフレームワークを多用しています。そのモックフレームワークは、プロジェクトが作成されたとき、またはプログラマーがテクニックを習得したとき、具象クラスのモックをサポートしていません（またはサポートしていません）。
各クラスへのインターフェースを持つことは極端です。あなたはその権利を発見しました。
ただし、インターフェイスを1つのクラスのみで実装することは、ご想像のとおり、それほど珍しいことではありません。アジャイルの原則に精通している場合、彼らは通常、インターフェースはクライアントに属していると言っています。これは論理的に正しく、技術的に実用的です。そのため、クライアントに動作を定義するインターフェースを作成し、実際のクラスを使用せずにクライアントをコンパイルすることで、コンパイル時間やモジュールの配信を削減できます。モジュールはインターフェースに依存するため、それらは独立して、具体的な実装なしで提供できます。あなたが望むようにあなたは単に実装を交換することができます。
これを極端にすると、あなたはあなたが見ているものを使いこなすことになります。それはまったく良くありませんが、インターフェースがまったくないほうが悪いでしょう。
一般的な推奨事項は実装ではなくインターフェイスにコーディングすることですが、これでは少しやりすぎませんか？
（IMO）はい。インプリメンターが1つだけのインターフェースがある場合、インターフェースは実際には必要ありません。
それは言った、多くの場所は常に2つの実装者を必要とします。実際の実装とそれを消費するものの単体テストを可能にするモック実装。オブジェクトが単なるデータである場合、またはテストで単独で使用できる場合は、すばらしいです。
インターフェースが理にかなっているもう1つのケースは、APIへのパブリックインターフェースとしてです。これは、（現時点では）実装者が1人しかいない場合でも、消費者を保護する役割を果たします。