Вопрос по dependency-injection – Является ли анти-шаблон для внедрения DI-контейнера в (почти) каждый класс?

1

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

Как-то у меня плохие чувства по поводу этого решения (кроме накладных расходов, связанных с доступом к контейнеру), но я не могу придумать слишком много недостатков. Может быть, свободное определение зависимостей может снизить переносимость класса, или я получаю сюрпризы при рефакторинге ...?

Что Вы думаете об этом

Смотрите также / Stackoverflow.com вопросы / 23931321 / ... Dan Blows
Внедрение контейнера в класс - это всего лишь форма анти-паттерна локатора службы, которая (почти) так же плоха, как и вызов статического экземпляра локатора служб Steven

Ваш Ответ

2   ответа
10

им не нужно знать или заботиться о том, что их вводят. Это не означает «не звоните нам; мы вам позвоним».

И наоборот: общее приложение знает о механизме DI, но затем получает нужные ему бины.

Полагаю, вы можете утверждать, что аннотации несколько меняют отношения, потому что теперь бобыделат знаю что-то о том, что они связаны друг с другом. Но когда конфигурация была перенесена в XML, это было верно, что бины не знали DI.

Хороший ответ, спасибо! gphilip
1

и я могу поспорить, что ты еще не пишешь тесты для своего кода, который действительно плох.

Когда вы начнете писать тесты, вы обнаружите, что вы пишете не тестируемый код, и вы:

Использование анти-шаблона Service Locator

Ты нарушаешь закон Деметры

Вы не следуете принципу единой ответственности

Вы скрываете реальные зависимости вашего объекта (не используя шаблон Dependency-Injection)

У вас нет реального разделения между двумя большими кучами объектов в любом приложении:

Бизнес-объекты: ответственность - бизнес-логика, абстракции доменов Проводка и построение объектов: ответственность заключается в построении графов объектов

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

Я советую прочитать это руководство, чтобы написать тестируемый код: (это руководство используется парнями, которые усердно работают в Google)

http: //misko.hevery.com/code-reviewers-guide

Если вы предпочитаете, начните с этих видео от Миско Хевери о психологии тестирования и разговорах о чистом коде:

http: //www.youtube.com/watch? v = wEhu57pih5w & функция = player_embedded

http: //www.youtube.com/watch? v = RlfLCWKxHJ0 & функция = player_embedded

http: //www.youtube.com/watch? v = -FRm3VPhseI & функция = player_embedded

Думаю, ты немного драматизируешь ситуацию. Я действительно пишу юнит-тесты для своих классов, и я не вижу, как определение осветителей в моем DI-контейнере вместо передачи их напрямую усложняет ситуацию. Я также не согласен с вашей точкой зрения о СРП, и только частично с тем, что вы говорите о законе Деметры (это контейнер). Вы подразумеваете здесь слишком много вещей. gphilip

Похожие вопросы