Инъекция бетонных классов считается плохой практикой

Question

Меня интересует принцип инверсии зависимостей в целом и необходимость его строгого соблюдения постоянно.

Я знаю, что использование интерфейсов для инъекции в целом способствует слабой связи, что оказывает положительное влияние.

Однако существуют определенные типы классов, которые, скорее всего, всегда будут иметь только одну реализацию и, вероятно, не изменятся со временем. Я действительно сомневаюсь, что все объекты поддерживаются интерфейсом, например, FooService, с FooServiceImpl.

Я нахожусь в дилемме, потому что я думаю, что инъекция конкретного класса, как правило, осуждается многими людьми.

ТЛ; др
Должно ли внедрение зависимостей всегда выполняться только с интерфейсами, даже если некоторые классы вряд ли изменятся, и, следовательно, его поддержка интерфейсом, кажется, добавляет нежелательную сложность?

Answer 1

Вы правы, Dependency Injection начинает приносить пользу, как только появляется более одной реализации. Я понимаю, что у вас есть только одна конкретная реализация, но если вы будете следовать рекомендациям лучших разработчиков, вы захотите провести модульное тестирование каждого класса. И если BarService зависит от вашего FooService, вы напишите модульный тест BarServiceTest, который полагается на поддельную реализацию FooService (макет или что-то в этом роде).

Другими словами, как только вы пишете модульное тестирование вашего приложения, вы в конечном итоге получаете реализацию своего сервиса: реальный, используемый во время выполнения, поддельный, используемый для модульного тестирования (или отдельную реализацию, но настроенную по-разному в зависимости от контекста).,

Answer 2

Просто пара вещей.

Dependency injection (DI) ==! Inversion of Control (IoC) ==! Dependency Inversion Principle (DIP)

Я не могу вспомнить лучшее (будучи таким же кратким и объяснительным) чтение по теме, кроме этой

Второй аспект зависит от языка и (или) инструментов. Конечно, я не могу говорить обо всех языках и их доступном стеке инструментов, но могут быть некоторые, где удвоение теста интерфейса будет лучшим подходом, чем генерация двойного в качестве дочернего класса моделируемого класса.

Так что мой личный (и субъективный) ответ для

Должно ли внедрение зависимостей всегда выполняться только с интерфейсами, даже если некоторые классы вряд ли изменятся, и, следовательно, его поддержка интерфейсом, кажется, добавляет нежелательную сложность?

определенно 'нет' из-за ненужной сложности в структуре классов. Кроме того, выполнение DI обычно означает, что для управления зависимостями используется какой-то контейнер ввода зависимостей, что, в свою очередь, требует дополнительных усилий по настройке.

Лично я представляю интерфейсы намеренно только тогда, когда у меня действительно есть такое намерение явно. Все остальные интерфейсы, которые появляются в коде, являются просто извлечением во время процесса разработки / рефакторинга (иными словами, я создаю такие абстракции только тогда, когда они нужны мне или моему коду).