Внедрение зависимостей и шаблон проектирования синглтонов

Как определить, когда использовать внедрение зависимостей или одноэлементный шаблон. Я читал на многих веб-сайтах, где говорится: «Используйте инъекцию зависимостей по шаблону singleton». Но я не уверен, что полностью согласен с ними. Для моих малых или средних проектов я определенно вижу простое использование одноэлементного шаблона.

Например Регистратор. Я мог бы использовать Logger.GetInstance().Log(...) Но, вместо этого, зачем мне вставлять каждый создаваемый мной класс с экземпляром регистратора ?.

Если вы хотите проверить, что регистрируется в тесте, вам понадобится внедрение зависимостей. Кроме того, регистратор редко бывает одиночным - обычно у вас есть регистратор для каждого вашего класса.

Посмотрите эту презентацию об объектно-ориентированном дизайне для тестирования, и вы поймете, почему синглтоны - это плохо.

Проблема синглтонов в том, что они представляют глобальное состояние, которое трудно предсказать, особенно в тестах.

Имейте в виду, что объект может быть де-факто одноэлементным, но все же получаться через внедрение зависимостей, а не через Singleton.getInstance().

Я просто перечисляю некоторые важные моменты, сделанные Миско Хевери в его презентации. После его просмотра , вы получите полную перспективу , почему это лучше иметь объект определить , что его зависимостей, но не определяют способ , как создать их.

Синглтоны похожи на коммунизм: они оба прекрасно звучат на бумаге, но на практике порождают проблемы.

В одноэлементном шаблоне непропорционально большое внимание уделяется простоте доступа к объектам. Он полностью избегает контекста, требуя, чтобы каждый потребитель использовал объект в области видимости домена приложения, не оставляя никаких вариантов для различных реализаций. Он встраивает знания об инфраструктуре в ваши классы (призыв к GetInstance()), добавляя ровно нулевую выразительную силу. Это фактически снижает вашу выразительную силу, потому что вы не можете изменить реализацию, используемую одним классом, не изменив ее для всех . Вы просто не можете добавить разовые функции.

Кроме того, когда класс Fooзависит от Logger.GetInstance(), Fooон эффективно скрывает свои зависимости от потребителей. Это означает, что вы не сможете полностью понять Fooили использовать его с уверенностью, если не прочитаете его источник и не обнаружите тот факт, от которого он зависит Logger. Если у вас нет исходного кода, это ограничивает ваше понимание и эффективное использование кода, от которого вы зависите.

Шаблон синглтона, реализованный с помощью статических свойств / методов, представляет собой не более чем хакерство по реализации инфраструктуры. Он ограничивает вас множеством способов, не предлагая заметных преимуществ по сравнению с альтернативами. Вы можете использовать его как хотите, но, поскольку есть жизнеспособные альтернативы, которые способствуют лучшему дизайну, это никогда не должно быть рекомендуемой практикой.

Другие очень хорошо объяснили проблему синглтонов в целом. Я просто хотел бы добавить примечание о конкретном случае Logger. Я согласен с вами, что обычно не проблема получить доступ к Регистратору (или корневому регистратору, если быть точным) как синглтону, через статический getInstance()или getRootLogger()метод. (если вы не хотите видеть, что регистрируется тестируемым вами классом - но по своему опыту я вряд ли могу вспомнить такие случаи, когда это было необходимо. Опять же, для других это может быть более насущной проблемой).

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

Альтернативой было бы внедрение регистратора через конструктор в (почти) каждый класс в вашем приложении. Для согласованности интерфейсов его следует вводить, даже если рассматриваемый класс в настоящее время ничего не регистрирует - альтернативой может быть то, что когда вы обнаружите в какой-то момент, что теперь вам нужно что-то регистрировать из этого класса, вам понадобится регистратор, таким образом вам нужно добавить параметр конструктора для DI, нарушив весь клиентский код. Мне не нравятся оба этих варианта, и я чувствую, что использование DI для регистрации просто усложнило бы мне жизнь, чтобы соответствовать теоретическому правилу, без какой-либо конкретной выгоды.

Итак, мой итог: класс, который используется (почти) повсеместно, но не содержит состояния, относящегося к вашему приложению, может быть безопасно реализован как Singleton .

В основном, но не только о тестах. Синглтоны были популярны, потому что их было легко потреблять, но у них есть ряд недостатков.

• Трудно проверить. Имеется в виду, как мне убедиться, что регистратор работает правильно.
• Трудно протестировать. Это означает, что если я тестирую код, который использует регистратор, но это не является целью моего теста, мне все равно нужно убедиться, что мой тестовый env поддерживает регистратор
• Иногда вам нужен не синглтон, а больше гибкости

DI дает вам простое использование ваших зависимых классов - просто поместите его в аргументы конструктора, и система предоставит его вам, при этом обеспечивая гибкость тестирования и построения.

Примерно единственный раз, когда вы должны когда-либо использовать Singleton вместо Dependency Injection, - это если Singleton представляет неизменяемое значение, такое как List.Empty или подобное (при условии неизменяемых списков).

Внутренняя проверка для синглтона должна быть такой: «Было бы хорошо, если бы это была глобальная переменная, а не синглтон?» В противном случае вы используете шаблон Singleton, чтобы скрыть глобальную переменную, и вам следует рассмотреть другой подход.

Только что прочитал статью о Monostate - это отличная альтернатива Singleton, но у нее есть некоторые странные свойства:

class Mono{
    public static $db;
    public function setDb($db){
       self::$db = $db;
    }

}

class Mapper extends Mono{
    //mapping procedure
    return $Entity;

    public function save($Entity);//requires database connection to be set
}

class Entity{
public function save(){
    $Mapper = new Mapper();
    $Mapper->save($this);//has same static reference to database class     
}

$Mapper = new Mapper();
$Mapper->setDb($db);

$User = $Mapper->find(1);
$User->save();

Разве это не страшно - потому что Mapper действительно зависит от соединения с базой данных для выполнения save () - но если другой сопоставитель был создан ранее - он может пропустить этот шаг при получении его зависимостей. В то время как аккуратно, это также немного беспорядочно, не так ли?

Существуют и другие альтернативы шаблонам Singleton: Proxy и MonoState.

http://www.objectmentor.com/resources/articles/SingletonAndMonostate.pdf

Как можно использовать шаблон прокси для замены синглтона?