Чи є ін'єкція бідної людини в залежність хорошим способом впровадження спадковості у спадщину програму?

Минулого року я створив нову систему, використовуючи Dependency Injection та контейнер IOC. Це мене багато чого навчило щодо DI!

Однак, навіть вивчивши поняття та правильні зразки, я вважаю викликом роз'єднати код та ввести контейнер IOC у застарілий додаток. Додаток є досить великим, щоб справжня реалізація була б величезною. Навіть якщо цінність була зрозуміла і час був наданий. Кому надано час на щось подібне ??

Мета звичайно - наблизити одиничні тести до бізнес-логіки!
Бізнес-логіка, що переплітається з тестовими викликами бази даних.

Я читав статті і розумію небезпеку ін'єкції залежності бідного чоловіка, як описано в цій статті Los Techies . Я розумію, це справді нічого не відриває.
Я розумію, що це може залучати багато системного рефакторингу, оскільки для реалізації потрібні нові залежності. Я б не розглядав можливість використовувати його в новому проекті з будь-якою величиною.

Запитання: Чи нормально використовувати DI Poor Man, щоб запровадити перевірку на застаріле додаток і розпочати прокатку кулі?

Окрім того, чи використання ІД бідного чоловіка як низового підходу до справжнього введення залежностей є цінним способом навчання необхідності та переваг цього принципу?

Чи можете ви рефакторувати метод, який має залежність від виклику бази даних та абстрактний, що викликає інтерфейс? Просто наявність цієї абстракції зробить те, що цей метод перевіряється, оскільки реалізація макету може бути передана через перевантаження конструктора.

Коли дороги наберуть прихильників, проект може бути оновлений для впровадження контейнера МОК, і там будуть конструктори, які беруть участь у абстракціях.

Критика щодо введення бідних людей у ​​NerdDinner має менший стосунок до того, чи використовуєте ви контейнер DI, чи не про правильне налаштування класів.

У статті вони констатують це

public class SearchController : Controller {

    IDinnerRepository dinnerRepository;

    public SearchController() : this(new DinnerRepository()) { }

    public SearchController(IDinnerRepository repository) {
        dinnerRepository = repository;
    }
}

невірно, оскільки, хоча перший конструктор забезпечує зручний механізм резервного спорудження класу, він також створює жорстко пов'язану залежність до DinnerRepository.

Правильний засіб, звичайно, полягає не в тому, як пропонує Los Techies, додавати контейнер DI, а скоріше видалити порушник.

public class SearchController : Controller 
{
    IDinnerRepository dinnerRepository;

    public SearchController(IDinnerRepository repository) {
        dinnerRepository = repository;
    }
}

Тепер у класу, що залишився, свої залежності правильно інвертовані. Тепер ти можеш вводити ці залежності, як би то не хотілося.

Ви робите помилкове припущення щодо того, що таке "DI DI бідолаха".

Створення класу, який має конструктор "ярликів", який все ще створює з'єднання , не є бідним чоловіком.

Якщо не використовувати контейнер, а створювати всі ін'єкції та карти вручну, це DI DI бідолахи.

Термін "бідний чоловік DI" звучить як погана справа. З цієї причини термін "чистий ДІ" заохочується в наші дні, оскільки він звучить більш позитивно і фактично більш точно описує процес.

Мало того, що користуватися бідними людьми / чистими ДІ не лише для введення ДІ в існуючу програму, але й правильним способом використання ДІ для багатьох нових програм. І як ви кажете, кожен повинен використовувати чистий DI принаймні в одному проекті, щоб дійсно зрозуміти, як працює DI, перш ніж передати відповідальність за "магію" контейнера IoC.

Зміна парагідів у застарілих командах / базах кодів надзвичайно ризикована:

Щоразу, коли ви пропонуєте "вдосконалити" застарілий код і в команді є "застарілі" програмісти, ви просто говорите всім, що "вони зробили це неправильно", і ви стаєте Ворогом на весь час / час роботи з компанією.

Використання DI Framework як молотка для розбиття всіх нігтів просто зробить застарілий код гіршим, ніж кращим у всіх випадках. Це також надзвичайно ризиковано особисто.

Навіть у найбільш обмежених випадках, таких як просто так, що їх можна використовувати в тестових випадках, вони просто зроблять ті тестові випадки "нестандартним" та "іноземним" кодом, які в кращому випадку просто помітяться, @Ignoreколи вони порушуються або ще гірше будуть скаржитися постійно застарілі програмісти з найбільшою мірою керування та керуються переписом "правильно" при всьому цьому "витрачений час на одиничні тести", звинувачений виключно на вас.

Якщо впровадити рамку DI, або навіть концепцію "Чистого DI", у додаток для бізнесу, набагато менше величезної спадкової бази коду без відключення управління, команди та особливо спонсорства провідного розробника буде просто смертним колом для вас соціально та політично в команді / компанії. Робити подібні речі є надзвичайно ризикованим та може бути найгіршим політичним самогубством.

Ін'єкційна залежність - це рішення, яке шукає проблему.

Будь-яка мова з конструкторами за визначенням використовує ін'єкцію залежності за умовою, якщо ви знаєте, що ви робите, і розумієте, як правильно використовувати конструктор, це просто хороший дизайн.

Ін'єкційна залежність корисна лише в невеликих дозах для дуже вузького кола речей:

• Речі, які сильно змінюються або мають багато альтернативних реалізацій, статично пов'язаних.

  • Драйвери JDBC - прекрасний приклад.
  • HTTP-клієнти, які можуть відрізнятися від платформи до платформи.
  • Системи лісозаготівлі залежать від платформи.

• Системи плагінів, які мають настроювані плагіни, які можна визначити у коді конфігурації у вашій рамці та виявляти автоматично при запуску та динамічно завантажувати / перезавантажувати під час роботи програми.