Почему всегда существуют единые интерфейсы реализации в сервисе и дао?

Я работал/видел несколько проектов веб-приложений 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 и т.д. Но Я все еще не понимаю прагматичную причину наличия в интерфейсе столь большого количества интерфейсов.