Почему всегда используются единственные интерфейсы реализации на уровне обслуживания и на уровне dao?

Я работал / видел несколько проектов веб-приложений spring-hibernate, имеющих столько интерфейсов, сколько существует реальных классов service и dao.

Я всегда думал, что эти две основные причины наличия этих единственных интерфейсов реализации:

1. Spring может связывать фактическую реализацию как зависимости в данном классе (слабая связь)

    открытый класс Person {
    @Autowired
   частный адресный адрес;
   
    @Autowired
   private AccountDetail accountDetail;
   
   публичное лицо (Address address, AccountDetail accountDetail)
    {// конструктор
   

2. Во время модульного тестирования я могу создавать фиктивные классы и тестировать класс изолированно.

    Адрес mockedAddress = mock (Адрес);
   AccountDetail mockedAccountDetail = mock (AccountDetail);
   Person underTestPerson = новый человек (mockedAddress, mockedAccountDetail);
   // модульный тест следует
   

Но в последнее время я понял, что:

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 на основе интерфейсов - это ДИЗАЙН, которому все следуют - они упоминают о лучших практиках Spring, ООП, DDD и т. Д. Но я все еще не понимайте прагматических причин наличия такого количества интерфейсов в изолированном приложении.