私が見たすべてのMVCプロジェクトでは、 "サービス"と "DAO"クラスは常に独自のインターフェイスを実装していました。しかし、ほとんどすべての時間、私はこのインターフェースを持つことが有用である状況を見ていない。サービスとDAOは常にインターフェイスを実装します
これらのケースでインターフェイスを使用する理由はありますか？ 「サービス」クラスと「DAO」クラスでインターフェイスを使用しないことの結果はどうでしょうか？私は結果を想像することはできません。
インターフェイスベースの実装は、テストスイートでそれらを嘲笑するのに役立ちます。私たちのプロジェクトでは、サービス層をテストしながら、実際にDBに接続するのではなく、DAOを模擬し、ハードコードされたデータを提供します。サービス層にも同じ議論が適用されます。
スプリングはInversion of Controlコンテナです。これは、ある意味では、使用するクラスの実装がアプリケーションにではなく、その構成に当てはまることを意味します。あなたがUserインスタンスを格納するUserRepositoryを必要とするクラスを持っている場合、それは
class UserService {
@Autowired
private UserRepository userRepository;
}
interface UserRepository {
List<User> getUsers();
User findUserBySIN(String SIN);
List<User> getUsersInCountry(Long couyntryId);
}
ようなものになるだろうそして、あなたは、このBeanがUserRepositoryHibernateImpl希望であること
<bean class="com.myapp.UserRepositoryHibernateImpl">
...
</bean>
お知らせのためにBeanを宣言しているだろうUserRepositoryを実装します。
将来のある時点では、Hibernateプロジェクトはサポートされなくなり、Mybatisでのみ利用可能な機能が必要になるため、実装を変更する必要があります。 UserServiceクラスはインターフェイスタイプで宣言されたUserRepositoryを使用しているため、インターフェイスに表示されているメソッドだけがクラスに表示されます。したがって、実際のポリモーフィックタイプuserRepositoryを変更しても、クライアントコードの残りの部分には影響しません。変更する必要があるのは、新しいクラスの作成を除いて
<bean class="com.myapp.future.UserRepositoryMyBatisImpl">
...
</bean>
です。アプリケーションは引き続き動作します。
しかし、あなたが 'UserRepositoryHibernateImpl'から' UserRepositoryMybatisImpl'に切り替えるならば、とにかくたくさんのコードを書く必要があります。だから間違いなくあなたのアプリケーションを再構築しています。 Javaの1行（ 'userRepository'の変数宣言）をXMLの1行（Bean宣言）を変更するよりも魅力的でないのはなぜですか？これは、インタフェースを優先するための議論ではありません。 –
'UserRepositoryHibernateImpl'と' UserRepositoryMybatisImpl'の両方が 'UserRepository'インターフェースを実装しています。すべてのインタラクションは、そのインタフェースを通じて行われます。したがって、後ろにあるものを切り替えるのは簡単です。クライアントは変更されません。それらが実装との特定のやりとりによって実行された場合、それと相互作用するコードを変更する必要があります。インターフェイスでは、あなたはそうしない。 Springでは、コンテキスト内で簡単な宣言を使って実装を指定することができます。 –
はい、私はそれをすべて理解しています。私はちょうど誇大宣伝に買わない。 –
インターフェイスには多くの議論があります（Googleを参照）。
私が言及した他の人のポイントに追加することができます
要するに、インターフェイスを持つだけでいいです！
インターフェイスを早期に使用すると、アプリケーションのスケーラビリティが向上し、アプリケーションを使用しないことの結果によってアプリケーションのスケーラビリティが犠牲になります。
私は最近、まったく同じ質問をしてきましたが、これまでに単一の実装クラスになることがわかっていてもインターフェイスを作成することは愚かであり、膨大なものになりました（もっと実用的言語はその感情を知るだろう）。これはもうひとつのコンパイルモジュールです。しばしば自分の内側の独身者を満足させるために作られたものです。
春はモジュール/コンポーネント指向のフレームワークに進化したように見えます。プログラマはブロックを作成し、フレームワークはそれをまとめてアセンブルします。これは、条件に一致する複数のBeanを持つことが問題であり、複雑になります（DIの目的を殺すような修飾子を使用することになります）。プログラマは必然的にタイプのあいまいさを回避して、必要な構成の量を最小限に抑え、理想的には任意のブロックを1つの「スロット」に収めるようにします。私の意見で
、DIの最大の利点は、それが（単に設定XMLで宣言されたクラスの種類を変更することで）実装を変更することを容易にすることはありませんが、それはこのように、それが容易になり、依存関係のより容易な分離を可能にすることを分離中の各成分を試験する。そのために1つの子インタフェースは必要ありません。
インターフェイスを抽出するためにクラスをリバースエンジニアリングするのは純粋に機械的な作業であるため、「別の実装を追加する必要がある場合はどうしたらよいでしょうか」と心配しません。引数。
免責事項：中小規模のアプリケーション開発者の意見。大規模なプロジェクトでは状況が変わると確信しています。
しかし、モックインターフェイスと同じように簡単にクラスをモックする模擬フレームワークがあります。私はこれをインターフェースを分離する議論としては見ません。 –