На этой неделе я изучал использование среды Typhoon для внедрения зависимостей. Я понял, что разделение конструкции объектов полезно для замены произвольных компонентов на макеты во время модульного тестирования, и до сих пор я видел преимущества только от этого.
Но я не могу не думать, что раньше, когда у меня был огромный класс контроллера представления, который имел десятки импортируемых заголовков, теперь у меня есть огромный фабричный класс, который имеет десятки импортируемых заголовков. Должен ли я избежать массового фабричного класса?
6
Через десять лет я ожидаю, что я возьму список синглов из Синглтона, но на этот раз по веским причинам. У этого есть некоторые хорошие использования, но я предлагаю быть очень осторожным, оценивая воздействие.
—
Балог Пал
Я не думаю, что внедрение зависимостей - это способ уменьшить сложность, но способ избежать неявных зависимостей (использование глобальных символов / свободных переменных) в пользу явных зависимостей (используйте явные параметры / связанные переменные). Итак, сложность все еще существует, но вы вынуждены иметь дело с ней, потому что вы делаете это явным образом в сигнатурах вашего метода / конструктора.
—
Джорджио
Обратите внимание, что практически любая система организации кода может быть описана как «просто перенос сложности в другое место». Речь идет не столько об устранении сложности, сколько об организации ее наиболее логичным и полезным способом.
Если вам нужно импортировать 50 заголовков, вы должны сделать это где-нибудь. DI помогает вам с более простым способом модульного тестирования вашего кода.
—
BЈовић
Итак, вы говорите, что теперь ваш контроллер сосредоточен на контроле, а ваша фабрика импорта заголовков сосредоточена на импорте заголовков? Как это может быть плохо, используете ли вы DI-фреймворк или нет?
—
фунтовые