Простое создание объекта с помощью DIY-DI?

Question

Недавно я наткнулся на эту замечательную статью Чеда Парри, озаглавленную «Сделай сам» или «Сделай сам себе инъекцию зависимости». Я нахожусь в положении, когда я еще не готов использовать IoC Framework, но я хочу идти в этом направлении. Похоже, DIY-DI - хороший первый шаг.

Однако, прочитав статью, я все еще немного растерялся из-за создания объекта. Вот простой пример:

Используя ручное внедрение зависимости конструктора (не DIY-DI), вот как нужно построить объект Hotel:

PowerGrid powerGrid;           // only one in the entire application
WaterSupply waterSupply;   // only one in the entire application

Staff staff;
Rooms rooms;
Hotel hotel(staff, rooms, powerGrid, waterSupply);

Создание всех этих объектов зависимости затрудняет создание объекта Hotel в отдельности, что означает, что написание модульных тестов для Hotel будет затруднено.

Упрощает ли использование DIY-DI?
Какое преимущество предоставляет DIY-DI по сравнению с ручным внедрением зависимостей в конструктор?

Answer 1

Нет разницы между тем, что вы называете DIY-DI, и ручным инжектором конструктора.

Если создать экземпляр Hotel слишком сложно, вы можете сделать две вещи:

• Создатьубедитесь, что зависимости выражаются либо как интерфейсы, либо как абстрактные базовые классы.Это позволяет вам тестировать класс Hotel изолированно, предоставляя Test Doubles , например, динамические макеты или аналогичные вместо конкретных классов.
• Если существует слишком много зависимостей, тогда refactorдля агрегации сервисов .

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

Answer 2

Подсказка для

Создание всех этих объектов зависимостей затрудняет создание объекта Hotel отдельно

Как я вижу, не должно быть никаких зависимостейсиние объекты на красные объекты.Объекты с разным временем жизни не должны зависеть друг от друга.Смотрите также: http://misko.hevery.com/2008/09/30/to-new-or-not-to-new/