Зачем создавать интерфейсы для классов с единственной реализацией

08 марта 2022, 23:40

С таким я столкнулся еще когда впервые узнал про DAO-слой, где один парень настойчиво рекомендовал не делать конкретную реализацию, а программировать через интерфейсы. Однако со временем возникает вопрос: зачем? Наверное все DAO-классы никогда не изменятся, а соответственно нет смысла для каждого из них создавать личный интерфейс. А даже если и изменится сама СУБД, то нужно лишь немного поменять синтаксис запросов. Вот так новости... Причем такое встречается и не только в DAO. Наверняка все видели, где вместо того, чтобы просто создать класс (например) ConnectHelper, люди создают интерфейс ConnectHelper, а потом и его реализацию по типу ConnectHelperImpl. При этом с огромной вероятностью никогда не придется создавать еще один класс, реализующий этот интерфейс. Поэтому мне совершенно непонятно - это норма или люди пытаются сделать свой код настолько гибким, что в итоге это идет во вред и захломляет код?

Answer 1

Это же архитектурный принцип. Как и многое другое, в малых приложениях(пэтпроектах) это скорее некий оверхед, нежели необходимость. И его ценность растет с ростом кодовой базы. Там не только с реализациями дела, правильно спроектированные интерфейсы в целом позволяют сделать код менее связанным и обеспечивают инверсию зависимостей. Я не буду подробно это расписывать здесь, ведь вы всегда можете почитать на эту тему главы по SOLID у Роберта Мартина в книге "Чистая архитектура", например.

Вместо вывода будет мое личное мнение, почему все же даже учитывая явный оверхед, по крайней мере на первых порах, стоит стараться следовать всем принципам чистого кода и чистой архитектуры: Если не привыкнуть к этому в небольших проектах, когда дело дойдет до больших, правильно реализовать все это не имея практики будет гораздо сложнее.