Daoデザインパターンまたは他のデザインパターンでインターフェイスを使用する理由
以下のDaoデザインパターンのコンポーネントを参照してください。
データアクセスオブジェクトパターンまたはDAOパターンは、低レベルのデータアクセスAPIまたは操作を高レベルのビジネスサービスから分離するために使用されます。以下は、データアクセスオブジェクトパターンの参加者です。
データアクセスオブジェクトインターフェイス-このインターフェイスは、モデルオブジェクトで実行される標準操作を定義します。
データアクセスオブジェクトの具象クラス-このクラスは上記のインターフェースを実装します。このクラスは、データベース/ xmlまたはその他のストレージメカニズムであるデータソースからデータを取得する責任があります。
モデルオブジェクトまたは値オブジェクト-このオブジェクトは、DAOクラスを使用して取得したデータを格納するget/setメソッドを含む単純なPOJOです。
具象クラスがあるのに、なぜINTERFACEが必要なのか、それを直接使用できないのはなぜですか。これは簡単な質問かもしれませんが、私がこのことを明確にするのを手伝ってください。 DAO設計パターンだけでなく、他の設計パターンでも、INTERFACEの使用は少し混乱します。これがコードの再利用性と結合の減少に関連していることに同意します。しかし、誰かがもう少し説明してください。
DAO設計パターンだけでなく、他の設計パターンでも、INTERFACEの使用は少し混乱します。
Interfacesは、Javaで最もよく使用される概念の1つです。例を挙げて説明しましょう。地図を調べ、自動的に車を地図に表示されている方向に向ける、自動車用のGPSデバイスを設計したとします。このGPSデバイスは、ベンツ、フィアットなどの多くの車で使用できます。各車では、左または右に曲がるメカニズムは、車のシステムの実装によって異なります。したがって、これらの関数は自動車メーカーが作成する必要があるため、これらのメソッドは、自動車の実装に応じて自動車メーカーが実装するインターフェースに配置されます。インターフェースには、自動車メーカー（この場合）が定義する関数宣言のセットのみが含まれています。とった？
インターフェースの詳細とインターフェースが役立つ理由については、 この記事 を参照してください。
私の質問は、具象クラスがあるのになぜINTERFACEが必要なのか、なぜそれを直接使用できないのか、です。
以下の回答で指摘されている他の多くの利点の中で、DAOインターフェースを実装するさまざまなデータコンストラクター（derby db、巨大なスタックなど）のために多くのDAOクラスを作成できます。利点は、すべてのクラスをDAOインターフェイス変数に格納できることです。これは、呼び出された polymorphism です。
実際、実装が1つしかない場合は、インターフェースを用意する必要はありません。しかし、具体的なクラスに依存しないことが非常に実用的である特定の状況があります。
DAOを呼び出すサービスのテスト：テストで必要なとおりに動作する模擬DAOを作成できます（例：DB接続がないため、自動的に再現するのが難しいシミュレーション）
dAOにいくつかのレイヤーを生成します。 AOPを使用して、DAOメソッドの周囲にキャッシングまたはトランザクション処理を生成できます。この場合、DAOインターフェースを実装するオブジェクトがありますが、元の実装とは何の関係もありません。
DBテクノロジーの切り替え。 MySQLからDB2に切り替える場合は、インターフェースの別の実装を記述して、MySQL DAOとDB2 DAOを切り替えるだけです。
したがって、DAOとサービスのインターフェースを用意することをお勧めします。
私の質問は、具象クラスがあるのになぜINTERFACEが必要なのか、なぜそれを直接使用できないのかということです。
それは単純な抽象化です。データベースとしてOracle Databaseを使用しているとします。したがって、具象クラスには、Oracle DBにアクセスするためのロジック（CRUD ops）があります。明日、ライセンスの有効期限が切れ、Oracle DBを使用したくない場合は、代わりにMySQLを使用します。ここで、すでに述べた具象クラスを書き直す必要があります。具象クラスとそのメソッドを直接使用することにより、サービスレイヤーとデータアクセスレイヤーの間の密結合があるため、サービスレイヤーも書き直す必要があります。常に疎結合を考慮してシステムを設計する必要があります。
具象クラスの代わりにインターフェースを使用する場合、サービスレイヤーとデータアクセスレイヤーには、相互作用方法の規約があります。したがって、コントラクトは変更されておらず、サービスレイヤーは同じ古い方法で相互作用できるため、サービスレイヤーはデータレイヤーの変更による影響を受けません。
インターフェースを実装から分離することは常に良い設計です。 abstractionおよびflexibilityをコードに提供します。 DAOインターフェースのクライアントは、それがどのように実装されているかを知る必要はなく、DAOインターフェースが提供するメソッドだけを知っている必要があります。
結局のところ、インターフェースはコードの保守性を向上させるための良い習慣です。
加えて、モックを介した単体テストでの私の経験では、モックするオブジェクトにインターフェイスがある場合、モックオブジェクトを作成する方がはるかに簡単です。したがって、私にとっては、インターフェイスを使用すると、分離とテストが簡単になりますあなたのコード。
アプリケーションをテストするためのモック実装を簡単に作成できるのは1つの理由です。
UserServiceを使用するモジュールXをテストするとします。テストコードを作成するときは、実際のUserServiceではなく、事前定義されたテストデータを返すUserServiceの特別なテストバージョンを使用する必要があります。したがって、テストでは、実際のUserServiceではなく、IUserServiceの独自のモック実装を渡します。
また、将来的には、IUserServiceの異なる実装を使用してシステムを拡張しやすくなります。データベースからユーザーに関する情報を読み取るUserServiceがあるかもしれません。たとえば、LDAPから情報を取得するUserServiceも必要になるかもしれません。これは、IUserServiceのもう1つの実装です。アプリケーションの残りの部分は、インターフェースを介してのみUserServiceを使用するため、1つの実装を別の実装に簡単に交換できます。
これは、コードの論理的な分離に関するものです。
インターフェースの詳細については、Javaからこのページをお読みください。
http://docs.Oracle.com/javase/tutorial/Java/concepts/interface.html