Якщо одиночні люди погані, то чому контейнер послуг хороший?

Ми всі знаємо, наскільки погані самотні , тому що вони приховують залежності та з інших причин .

Але у фреймворку може бути багато об’єктів, які потрібно створити лише один раз і викликати їх звідусіль (реєстратор, db тощо).

Для вирішення цієї проблеми мені сказали використовувати так званий "Менеджер об’єктів" (або Службовий контейнер, як symfony), який внутрішньо зберігає кожне посилання на Служби (реєстратор тощо).

Але чому постачальник послуг не такий поганий, як чистий синглтон?

Постачальник послуг теж приховує залежності, і вони просто завершують створення першої істанції. Тож я справді намагаюся зрозуміти, чому нам слід використовувати постачальника послуг замість одинарних.

PS. Я знаю, що, щоб не приховувати залежностей, я повинен використовувати DI (як зазначив Місько)

Додати

Я б додав: У наші дні одинокі не такі вже й злі, це пояснив творець PHPUnit:

• http://sebastian-bergmann.de/archives/882-Testing-Code-That-Uses-Singletons.html

DI + Singleton вирішує проблему:

<?php
class Client {

    public function doSomething(Singleton $singleton = NULL){

        if ($singleton === NULL) {
            $singleton = Singleton::getInstance();
        }

        // ...
    }
}
?>

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

Крім DI та Service Container, чи є якесь прийнятне рішення для доступу до цих допоміжних об'єктів?

Локатор послуг - це, як можна сказати, лише одне з двох зол. "Менший" зводиться до цих чотирьох відмінностей ( принаймні я зараз не можу думати про жодні інші ):

Принцип єдиної відповідальності

Контейнер послуг не порушує Принцип єдиної відповідальності, як це робить Singleton. Сінглтони поєднують створення об’єктів та бізнес-логіку, тоді як Службовий контейнер несе сувору відповідальність за управління життєвим циклом об’єкта вашої програми. У цьому відношенні Контейнер послуг кращий.

Зчеплення

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

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

Приховані залежності

Проблема приховування залежностей існує дуже багато. Коли ви просто вводите локатор у ваші споживаючі класи, ви не знаєте ніяких залежностей. Але на відміну від Сінглтона, SL зазвичай створює всі необхідні кулуарні залежності. Отже, коли ви отримуєте Службу, ви не опиняєтесь , як Місько Хевері в прикладі CreditCard , наприклад, вам не доведеться створювати екземпляри всіх депеденцій залежностей вручну.

Отримання залежностей всередині екземпляра також порушує Закон Деметри , який говорить, що не слід копатись у співавторах. Екземпляр повинен говорити лише зі своїми безпосередніми співробітниками. Це проблема як із Singleton, так і з ServiceLocator.

Глобальна держава

Проблема глобального стану також дещо пом'якшена, оскільки при створенні екземпляра нового Службового локатора між тестами також видаляються всі створені раніше екземпляри (якщо ви не допустили помилки та не зберегли їх у статичних атрибутах у SL). Звичайно, це не справедливо для будь-якої глобальної держави в класах, якими керує СЛ.

Також дивіться Фаулера про Службу пошуку локаторів проти введення залежностей для набагато більш глибокого обговорення.

Примітка до вашого оновлення та пов’язана стаття Себастьяна Бергмана про тестування коду, який використовує Singletons : Себастьян жодним чином не припускає, що запропонований обхідний шлях робить використання Singleons меншою проблемою. Це лише один із способів зробити код, який інакше було б неможливо перевірити більш перевіреним. Але це все ще проблематичний код. Насправді він прямо зазначає: "Те, що ти можеш, не означає, що ти повинен".

Шаблон локатора послуг є анти-шаблоном. Це не вирішує проблему викриття залежностей (ви не можете зрозуміти, дивлячись на визначення класу, що це за залежності, оскільки вони не вводяться, а витягуються з локатора служби).

Отже, ваше запитання: чому локатори послуг хороші? Моя відповідь така: вони ні.

Уникайте, уникайте, уникайте.

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

Наскільки я розумію, єдина відмінність між ними полягає в тому, що в службовому контейнері службовим контейнером є об'єкт, що вводиться (таким чином, приховуючи залежності), коли ви використовуєте DIC, DIC вводить відповідні для вас залежності. Клас, яким керує DIC, абсолютно не пам’ятає, що він управляється DIC, отже, у вас менше зв’язку, чітких залежностей і щасливих модульних тестів.

Це гарне запитання в SO, що пояснює різницю в обох: Яка різниця між моделями введення залежностей та шаблонами служб локатора?

Оскільки ви можете легко замінити об'єкти в Service Container на
1) успадкування (клас Object Manager можна успадкувати, а методи можна замінити)
2) зміна конфігурації (у випадку з Symfony)

І, Singletons погано не тільки з - за сильного зв'язку, а тому , що вони _ Поодинокі _tons. Це неправильна архітектура майже для всіх видів об’єктів.

За "чистий" DI (у конструкторах) ви заплатите дуже велику ціну - всі об'єкти повинні бути створені перед передачею в конструктор. Це означатиме більше використаної пам'яті та меншу продуктивність. Крім того, не завжди об'єкт можна просто створити і передати у конструкторі - можна створити ланцюжок залежностей ... Моя англійська мова недостатньо хороша, щоб обговорити це повністю, прочитайте про це в документації Symfony.

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

Наприклад, у мене є інтерфейс і адміністратор. Усередині адміністратора я хочу, щоб вони могли входити як користувач. Розглянемо код всередині адміністратора.

$frontend = new Frontend();
$frontend->auth->login($_GET['user']);
$frontend->redirect('/');

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

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

$logger1=$api->add('Logger');
$logger2=$api->add('Logger');

залишив би вам один екземпляр і обидві змінні, що вказують на нього.

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