вот если взять среднестатистическое спринг приложение, микросервис. Нужны ли интерфейсы в ём под каждую компоненту? В спринге же можно подключать классы напрямую.
В тестах можно мокать классы, теоретически для тестов не нужно подменять компоненты.
Я понимаю, зачем нужны интерфейсы, но как часто нужно подменять компоненты, если вообще? Чаще лежат файлы с интерфейсами, в проекте по сути не используемые. Что само собой нарушает SOLID ))) Там где это надо и так понятно, что нужен интерфейс. Возможно для интеграционных тестов нужны будут разные компоненты, для продуктивной и интеграционной сред. Это все понятно и надо будет делать. Но там где это действительно необходимо.
Вообщем я решил забить на них в своих проектах и подключать в компонентах не интерфейсы, а сами используемые компоненты. Это по моему мнению упрощает структуру проекта. Но боюсь старшие товарищи меня заругают, скажут так неправильно, не solidно, зависимости, непричесанные интерфейсы, трудно отслеживать single responsibility.
Вообщем я решил забить на них в своих проектах и подключать в компонентах не интерфейсы, а сами используемые компоненты.
Ничего не знаю конкретно за Java, но в целом в программировании все так и делают, если на проекте не принята явно жёстко схема с интерфейсами подо всё.
Вам виднее, нужны ли они в вашем проекте. Обычно это зависит от сложности проекта и темпов его развития. В чëм-то мелком и мало изменчивом внедрение через интерфейсы - это карго-культ. В большом и сложном проекте, который постоянно изменяется - это жизненно необходимый подход, без которого работа сначала превращается в ад, а потом и вовсе становится невозможна.
Между мелким и мало изменчивым и большим, сложным и постоянно меняющимся, есть ещё средние проекты, которых, имхо, большинство :)
А большие проекты как раз часто неповоротливы в плане "заменить реализацию интерфейса на что-то другое", там сидят староверы, которые своё легаси лишний раз стараются глобально не трогать. А когда всё-таки приходит нужда трогать, они это воспринимают как прекрасную возможность чуть-чуть порефакторить и уменьшить техдолг и переписывают половину приложения, включая те самые интерфейсы :)
Вообщем я решил забить на них в своих проектах и подключать в компонентах не интерфейсы, а сами используемые компоненты. Это по моему мнению упрощает структуру проекта. Но боюсь старшие товарищи меня заругают, скажут так неправильно, не solidно, зависимости, непричесанные интерфейсы, трудно отслеживать single responsibility.
Вопросы правильные и интересные.
Spring вообще очень сильно девальвировал ООП. Он превнес туда целый спектр вопросов в части аспектного программирования. Аннотации SpringData, SpringWeb, SpringSecurity. И поэтому само по себе обсуждение ООП стало вторичным. Важнее Bean. Lifecycle бина. Способы его инжекции в другие бины и прочее.
Кстати предлагаю тебе ради интереса взять какой-то pet-проект и просто переписать его без Spring. Хороший творческий челлендж. Я так делал. Потом можно попробовать Dagger2 / Guice в качестве инжекторного двигателя добавить сбоку. Там правда будет меньше других возможностей но мне кажется что для большинства проектов этого достаточно. А может быть проект даже станет проще.
Это кстати прямое следованию принципов KISS/Yagni. Так что твои коллеги-теоретики потеряют часть своих аргументов. Будешь бить их простотой. Santa simplicitas.
Простой
