Я работал/видел несколько проектов веб-приложений spring -hibernate, имеющих столько интерфейсов, что есть фактические классы обслуживания и дао.
Я всегда думал, что эти два являются основными причинами наличия этих единых интерфейсов реализации:
-
Spring может связать фактическую реализацию в качестве зависимостей в данном классе (свободная связь)
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
Но в последнее время я понял, что:
Spring может использовать конкретные классы реализации в качестве зависимостей:
public class Person {
@Autowired
private AddressImpl address;
@Autowired
private AccountDetailImpl accountDetail;
public Person(AddressImpl address, AccountDetailImpl accountDetail) {
// constructor
Макетные фреймворки, такие как EasyMock, могут также издеваться над конкретными классами
AddressImpl mockedAddress = mock(AddressImpl);
AccountDetailImpl mockedAccountDetail = mock(AccountDetailImpl);
Person underTestPerson = new Person(mockedAddress, mockedAccountDetail);
// unit test follows
Также, согласно этой дискуссии, я думаю, что резюме состоит в том, что в одном приложении интерфейсы в основном злоупотребляются, вероятно, из-за соглашения или привычки. Как правило, они имеют лучший смысл в тех случаях, когда мы взаимодействуем с другим приложением, например slf4j, используемым многими приложениями по всему миру. В одном приложении класс почти такой же абстракции, как и интерфейс.
Итак, мой вопрос, почему мы все еще нуждаемся в интерфейсах, а затем имеем единые реализации, такие как * ServiceImpl и * DaoImpl классы и излишне увеличиваем размер базы кода. Есть ли какая-то проблема в насмешливых конкретных классах, о которых я не знаю.
Всякий раз, когда я обсуждал это с моими товарищами по команде, только ответ, который я получаю, заключается в том, что внедрение сервисов и классов dao на основе интерфейсов - это DESIGN, которые следуют за ними - они упоминают о spring лучших практиках, ООП, DDD и т.д. Но Я все еще не понимаю прагматичную причину наличия в интерфейсе столь большого количества интерфейсов.
