Блог

Мне сказали, что синглтоны сложно тестировать.

• http://misko.hevery.com/2008/08/17/singletons-are-pathological-liars/
• http://misko.hevery.com/code-reviewers-guide/flaw-brittle-global-state-singletons/

Мне сказали, что статические методы / объекты тоже никуда не годятся.

• http://misko.hevery.com/2008/12/15/static-methods-are-death-to-testability/

Таким образом, в основном единственным решением, похоже, является внедрение зависимостей.

Но … Я действительно не могу привыкнуть к DI, возьмите этот пример:

В моем фреймворке у меня есть класс, который управляет SQL. Этот класс (и многие другие мои фреймворки) использует одноэлементный регистратор для регистрации сообщений (и многие другие помощники).

С DI мой код превратился бы в:

 global $logger; //> consider i have been instanciated it at the start of my fw

$query = new PreparedQuery($logger);
$query->prepare() etc.
  

Теперь это не кажется таким уж плохим. Но рассмотрим страницу, которая требует много запросов, я считаю, что довольно избыточно каждый раз писать $logger в конструкторе, особенно если учесть, что PreparedQuery требовалось много других зависимостей в конструкторе.

Единственное решение избежать одноэлементности, которое я нашел, — это использовать метод (или просто простую функцию) в основном приложении, в котором хранятся все ссылки на эти вспомогательные объекты (Service Locator / Container), но это не решает проблему сокрытия зависимостей

Итак, по вашему опыту, кроме DI, какой хороший шаблон использовать?

Решение:

Для всех интересующихся создатель PHPUnit объясняет, как решить проблему с одноэлементными объектами (и как решить проблему тестирования статических методов с PHP 5.3)

• (одноэлементный) http://sebastian-bergmann.de/archives/882-Testing-Code-That-Uses-Singletons.html
• (статический) http://sebastian-bergmann.de/archives/883-Stubbing-and-Mocking-Static-Methods.html

Довольно интересное чтение, если вы спросите меня.

Пожалуйста, не используйте global .
Вам нужно передать $logger в конструкторах или вместо этого передать Service Container (также известный как Objects manager, Service Locator, Resources Manager).
Вариант из Symfony Framework http://symfony.com/doc/current/book/service_container.html
Вы можете создать свой собственный диспетчер объектов, и его методы не должны быть статическими.

Ну, в этом случае я бы вместо этого создал builder (или factory). Итак, ваша фабрика внедрила бы зависимость для вас. Таким образом, вы также можете избежать своих глобальных:

 class PreparedQueryFactory {
    protected $logger = null;
    public function __construct($loggger) {
        $this->logger = $logger;
    }
    public function create() {
        return new PreparedQuery($this->logger);
    }
}
  

Таким образом, вы делаете один раз:

 $factory = new PreparedQueryFactory($logger);
  

Тогда в любое время, когда вам нужен новый запрос, просто вызовите:

 $query = $factory->create();
  

Итак, это очень простой пример. Но вы могли бы добавить всевозможную сложную логику, если вам нужно. Но суть в том, что, избегая new в своем коде, вы также избегаете управления зависимостями. Таким образом, вместо этого вы можете передавать фабрики по мере необходимости.

Преимущество заключается в том, что все это на 100% тестируемо, поскольку все внедряется везде (в отличие от использования глобальных).

Вы также можете использовать реестр (иначе известный как Service Container или контейнер DI), но убедитесь, что вы вводите реестр в.

Ведение журнала обычно является тем примером, когда статические синглтоны в порядке. Вам в любом случае не нужно издеваться над вашим протоколированием, не так ли?

Приведенные выше ответы дают вам несколько идей. Я представлю еще одно: реализовать архитектуру плагина. Регистратор становится плагином, который вы можете включать / отключать / изменять, когда захотите.

Упрощенный пример:

 class Logger implements Observer {
    public function notify($tellMeWhatHappened) {
         // oh really? let me do xyz
    }
}

class Query implements Observable {
    private $observers = array();

    public function addObserver(Observer $observer) {
        $this->observers[] = $observer;
    }

    public function foo() {
        // great code
        foreach ($this->observers as $observer) { $observer->notify('did not work'); }
    }
}
  

Это удаляет регистратор из конструктора. Это то, что я предпочитаю, если это не важно для функционирования объекта.

В моем понимании выступлений Миско Хевери о DI и new операторе проблема в том, что вы не зашли достаточно далеко в реализации DI.

Что он всегда говорит, так это то, что вы не должны смешивать бизнес-логику с построением объектов. Однако в двух строках вашего примера первая ( $query = new PreparedQuery($logger); ) создает объект, а затем вторая ( $query->prepare(/* ... */); ) — бизнес-логику.

Очевидно, что цель этого кода — подготовить запрос, и вместо того, чтобы беспокоиться о том, как создать PreparedQuery , он должен просто запросить его в конструкторе класса. Или, если ему нужно иметь возможность выдавать множество подготовленных запросов, он должен запросить прототип (который он будет клонировать всякий раз, когда ему понадобится новый) или объект factory. Дело в том, что тот факт, что в PreparedQuery есть logger, не имеет значения, и о нем следует позаботиться где-то в другом месте.

Принцип «запрашивать то, что вам нужно» в конструкторе, в принципе, легко понять, хотя я все еще пытаюсь разобраться для себя, что это означает на практике в различных ситуациях, и как реализовать его вплоть до вершины («основной метод» или эквивалент). Тем не менее, я думаю, что этот принцип говорит об общей проблеме, с которой вы столкнулись. Этот new оператор не должен находиться там, где он есть в первую очередь.