На цьому тижні я розглядав можливість використання рамки Тайфуна для введення залежності. Я розумію, що розділення конструкції об'єктів вигідно для заміни довільних компонентів макетами під час тестування одиниць, і поки що я бачив вигоди лише від цього.
Але я не можу не думати, що там, де раніше у мене був гумористичний клас контролера подання, який мав десятки імпорту заголовків, тепер у мене є гумористичний заводський клас, який має десятки імпорту заголовків. Чи повинен я уникати масового фабричного класу?
6
Через десятиліття я очікую, що DI візьме переломний список від Singleton, але цього разу з поважних причин. Він має корисні результати, але я пропоную дуже ретельно оцінювати їх вплив.
—
Balog Pal
Я не думаю, що введення залежності - це спосіб зменшити складність, але спосіб уникнути неявних залежностей (використання глобальних символів / вільних змінних) на користь явних залежностей (використовувати явні параметри / зв'язані змінні). Отже, складність все-таки є, але ви змушені з цим розібратися, тому що ви робите це явним підписом у методі / конструкторі.
—
Джорджіо
Зауважте, що майже будь-яка система організації коду може бути описана як "просто переміщення складності кудись інше". Мова йде не про те, щоб зняти складність настільки, як організувати її найбільш логічним, корисним способом.
Якщо вам доведеться імпортувати 50 заголовків, ви повинні це зробити десь. DI допоможе вам простішим способом тестування коду.
—
BЈоviћ
Отже, ви кажете, що зараз ваш контролер зосереджений на контролі, а фабрика імпорту заголовка зосереджена на імпорті заголовків? Як це може колись бути поганим, використовуєте ви рамку DI чи ні?
—
пдр