Ін'єкційна залежність та синглтон. Це два абсолютно різні поняття?

Я чула про використання ін'єкції залежності від Singleton для свого колеги. Я досі не можу зрозуміти, чи це два ортогональні візерунки, які можна замінити один на одного? Або DI це метод зробити шаблон Singleton перевіряючим?

Погляньте на наступний фрагмент коду.

    IMathFace obj = Singleton.Instance;

    SingletonConsumer singConsumer = new SingletonConsumer(obj);

    singConsumer.ConsumerAdd(10,20);

Параметр типу SingletonConsumer- це прийняття IMathFace. Замість доступу до класу синглтон внутрішньо, SingletonConsumerотримає одиночний екземпляр, переданий абонентом. Це хороший приклад споживання однокласного класу через ін'єкцію залежності?

Я думаю, він мав на увазі, що ви повинні використовувати ін'єкцію залежності, щоб ввести один екземпляр послуги, а не використовувати класичну реалізацію Singleton зі статичним аксесуаром MySingleton.Instance.

public class MySingleton
{
    public static MySingleton Instance{get{...}};
}

З класичною реалізацією синглтона весь ваш код залежить від того, що ця послуга є однотонною. Ви в основному жорсткий код цього припущення, щоб споживати код, коли ви використовуєте MySingleton.Instance.

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

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

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

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

Є один випадок, коли малюнок Сінглтона та DI / IoC перетинаються - введення синглтона.

Більшість фреймворків DI можуть бути налаштовані для екземпляра одного екземпляра введеного об'єкта. Будь-який споживчий об'єкт, який запитує екземпляр такого об’єкта, отримає той самий один екземпляр. Цей екземпляр є за визначенням Singleton. Ось про це для перекриття в концепції.

Плутанина тут полягає в тому, що були поєднані дві концепції: одиночний та статичний доступ / шлюз до екземпляра сингтона.

Як ви правильно визначили, ваш колега пропонує ввести залежність, а не отримати доступ безпосередньо, використовуючи Singleton.Instance(статичний шлюз).

Причина, що це насправді не має нічого спільного з одинарною схемою, полягає в тому, що та сама концепція DI застосовується однаково до інстанціювання об'єкта, що не є однотонним new Foo() . Залежність буде вводитися незалежно від того, чи є це однократною реалізацією.