私は実際のサービスとDAOのクラスと同じ数のインターフェースを持つ、いくつかのSpringHibernate Webアプリケーションプロジェクトを見ました。なぜサービスとDAOのレイヤーには常に1つのimplementaionインターフェイスがありますか？
私は常にこれらのこれらの単一の実装インタフェースを有する主な理由のような2つのことを考えた：
スプリングが所与のクラス（疎結合）
public class Person { @Autowired private Address address; @Autowired private AccountDetail accountDetail; public Person(Address address, AccountDetail accountDetail) { // constructor- における依存関係として実際の実装を配線することができ
単体テストでは、モッククラスを作成し、クラスを単独でテストできます。
Address mockedAddress = mock(Address); AccountDetail mockedAccountDetail = mock(AccountDetail); Person underTestPerson = new Person(mockedAddress, mockedAccountDetail); // unit test follows
しかし、後半の、私が気づい：
春の依存関係として、具体的な実装クラスを配線することができます：EasyMockのような
public class Person {
@Autowired
private AddressImpl address;
@Autowired
private AccountDetailImpl accountDetail;
public Person(AddressImpl address, AccountDetailImpl accountDetail) {
// constructor
モックフレームワークは、同様に具体的なクラスをモックすることができます
AddressImpl mockedAddress = mock(AddressImpl);
AccountDetailImpl mockedAccountDetail = mock(AccountDetailImpl);
Person underTestPerson = new Person(mockedAddress, mockedAccountDetail);
// unit test follows
また、this議論のように、私は概要は、単一のアプリケーション内では、インターフェイスは、おそらく大会や習慣からおそらく過度に使用されていると思う。一般的には、世界中の多くのアプリで使用されているslf4jなどの別のアプリケーションと接続する場合に最適です。 1つのアプリケーション内では、クラスはインターフェイスとほぼ同じ抽象化されています。
私はまだインターフェイスが必要なのですが、* ServiceImplや* DaoImplクラスのような単一の実装を持ち、コードベースサイズを不必要に増やすのはなぜですか？私が気づいていない具体的なクラスを模擬することにいくつかの問題がありますか？
これまで私がチームメイトと話したことがあるときは、インタフェースに基づいたサービスとDAOのクラスを実装することは誰もが守っているデザインだと言います - 彼らは春のベストプラクティス、OOP、DDDなどについて言います。孤立したアプリケーション内に非常に多くのインターフェースを持つことの後で、まだ実用的な理由はありません。
答えにつきましては、各オブジェクトの前にインタフェースを投げる理由としてDDDをどのように呼び出すことができないのか分かりません。 DDDはそれとは関係ありません。 OOPであっても、正当な理由がありません。あなたがSOLIDのL、I、Dのようなものを取るならば、インタフェースなどの抽象化をどのように設計すればよいのか、それらをいつ使うべきかを指定するだけです*。 あなたが言ったように、私はそれがすべて「春のベストプラクティス」のものか、それを習慣からやっている人だけに沸き起こると思います。 – guillaume31