インターフェイスに対するプログラミングは良い習慣であることに同意します。ほとんどの場合、この意味での Java の「インターフェース」は言語構成インターフェースを意味するため、インターフェースと実装クラスを作成し、ほとんどの場合、実装クラスの代わりにインターフェースを使用します。
これは、ドメイン モデルを作成するための良い方法でもあるのではないでしょうか。たとえば、ドメイン クラス Customer があり、各顧客が Orders のリストを持っている場合、通常はインターフェイス ICustomer および IOrder も記述します。また、Customer は Orders の代わりに IOrders のリストを持っていますか? それとも、ドメイン モデルでインターフェイスを使用するのは、それが実際にドメインによって駆動される場合のみです。たとえば、少なくとも 2 つの異なる種類の注文がある場合などです。言い換えれば、ドメイン モデルの技術的な必要性のためだけにインターフェースを使用しますか、それとも実際のドメインに関して本当に適切な場合にのみインターフェースを使用しますか?
KISS の原則に反することは言うまでもなく、「ただの理由で」インターフェースを書くことは、時間とエネルギーの無駄に思えます。
私は、それらが関連するクラスの一般的な動作を表現するのに実際に役立つ場合にのみ、単なる派手なヘッダー ファイルとしてではなく、それらを記述します。
システムを過度に設計しないでください。いくつかの種類の Orders があることがわかり、必要に応じてリファクタリングするよりも Orders のインターフェイスを宣言することが適切であると思われる場合。ドメイン モデルの場合、特定のインターフェイスが開発期間中に大幅に変更される可能性が高いため、早い段階でインターフェイスを作成することはほとんど役に立ちません。
インターフェイスは、単体テストの目的と一般的な依存関係管理のためにコンポーネントを分離する優れた方法です。そうは言っても、私は抽象クラスを好むことが多いので、インターフェイスがもたらす重複の一部を強制するのではなく、少なくとも共通の動作の一部をそこでオフロードします。最新の IDE では、インターフェイスをすばやく簡単に生成できるため、それほど手間がかかりません :-)
いいえ、私はドメイン オブジェクトのインターフェイスのみを使用して、それらを疎結合に保ちます。私にとって、インターフェイスを使用して独自のコードを開発する主な理由は、単体テストを行うときにモックを簡単に作成できることです。サービス層や DAO 層クラスと同じ依存関係がないため、ドメイン オブジェクトをモックする意味がわかりません。
これは確かに、ドメイン オブジェクトでインターフェイスを使用することから逸脱するという意味ではありません。適切な場所で使用してください。たとえば、最近、さまざまな種類のドメイン オブジェクトが、ユーザーがコメントを残すことができるパーマリンク ページに対応する Web アプリケーションに取り組んでいます。そのため、これらのドメイン オブジェクトのそれぞれが「コメント可能」インターフェイスを実装するようになりました。コメント ベースのコードはすべて、ドメイン オブジェクトの代わりに Commentable インターフェイスにプログラムされます。
実際、この質問は「インターフェースに対するプログラミング」に関するよくある誤解の一例です。
おわかりのように、これは非常に優れた原則ですが、多くの人が考えていることを意味するものではありません!
「実装ではなくインターフェイスへのプログラム」(GoF book から) は、単にそれを意味するだけであり、すべてに対して個別のインターフェイスを作成するためにわざわざ行くべきではないという意味です。オブジェクトがある場合はArrayList、変数/フィールド/パラメーター/戻り値の型を type として宣言しますList。クライアント コードは、インターフェイス タイプのみを処理します。
Joshua Bloch の著書「Effective Java」では、「項目 52: インターフェースによってオブジェクトを参照する」で、原則がより明確に表現されています。さらに、太字で次のように述べています。
適切なインターフェースが存在しない場合、インターフェースではなくクラスによってオブジェクトを参照することは完全に適切です。
単体テストの場合、状況は使用するモック ツールの機能に完全に依存します。私自身のツールであるJMockitを使用すると、テスト対象のコード内からインスタンス化された最終クラスを使用するコードと同じように、インターフェイスと依存性注入を使用するコードの単体テストを簡単に作成できます。
したがって、私にとっての答えは次のとおりです。常に既存のインターフェースを使用しますが、そうする正当な理由がない場合は新しいインターフェースを作成しないでください（そして、testability自体はそうすべきではありません）。
(テストまたはアーキテクチャのいずれかで) 必要になる前にインターフェイスを記述するのはやり過ぎです。
さらに、インターフェースを手動で作成するのは時間の無駄です。Resharper のリファクタリング「プル メンバー」を使用して、特定のクラスから数秒で新しいインターフェイスを作成できます。IDE と統合する他のリファクタリング ツールにも同様の機能が必要です。
インターフェイスに対するプログラミングの主な理由は、テストのしやすさだと思います。したがって、ドメインオブジェクトの場合は、POJOまたはPOC＃Oに固執するだけです:)など。つまり、クラスが特定のフレームワークを追加しないようにして、ビルドとランタイムの依存関係が異なるのを防ぎます。これですべてです。ただし、DAOのインターフェイスを作成することは良い考えです。
*ドメイン オブジェクトのプロキシを作成するために必要なためです。
単体テストに使用する場合、ドメイン クラスのインターフェイスを記述することは理にかなっています。単体テストでは Mock オブジェクトを使用します。したがって、ドメイン オブジェクトのインターフェースがあり、ドメイン オブジェクト自体の準備ができていない場合でも、クライアントはモック オブジェクトを使用してインターフェースの使用をテストできます。
インターフェイスは、ドメイン モデルのインターフェイスの複数の実装もテストします。ですから、決してやり過ぎだとは思いません。
私は通常、小規模なプロジェクトで意味のあるインターフェイスのみを使用します。しかし、私の最近の仕事には、ほぼすべてのドメイン オブジェクトがインターフェイスを持つ大規模なプロジェクトがあります。それはおそらくやり過ぎであり、間違いなく面倒ですが、Spring を依存性注入のためにテストして使用する方法には、それが必要です。
主に Wicket、Spring、Hibernate を使用して Web アプリケーションを作成し、サービスや DAO などの Spring Bean のインターフェイスを使用します。これらのクラスでは、インターフェイスは完全に理にかなっています。しかし、私たちはすべての単一のドメイン クラスに対してインターフェイスも使用しています。これはやり過ぎだと思います。
モデル オブジェクトの具象型が 1 つしかないと確信している場合でも、インターフェイスを使用すると、モック化とテストがいくらか簡単になります (ただし、最近では、具象 Java クラスであっても、モック クラスを自動的に生成するのに役立つフレームワークがあります。 Mockito、JTestR、Spring、Groovy...)
しかし、私はより頻繁にサービスのインターフェースを使用します。テスト中にそれらをモックすることがさらに重要であり、インターフェースに対するプログラミングは、カプセル化などについて考えるのに役立つからです。
テスト (モック) や AOP のようなものを支援するという理由だけで、すべてからインターフェイスを抽出します。Eclipse はこれを自動的に行うことができます: Refactor->Extract Interface。
後でクラスを変更する必要がある場合は、Refactor->Pull Up... を使用して、必要なメソッドをインターフェイスにプルアップできます。
これは、特に生成されたドメインと DAO オブジェクトに関して、私が遭遇したことを覚えておくべきもう 1 つのことです。多くのインターフェースはあまりにも具体的です。多くのドメイン オブジェクトが ID とステータス フィールドを持っているとします。共通のインターフェイスを共有しないのはなぜでしょうか? これは、不必要にフラットな (継承に関して) ドメイン モデルであるというフラストレーションを引き起こしました。