Паттерн «Синглтон»

Назначение: гарантирует, что у класса есть только один экземпляр, и предоставляет глобальную точку доступа к нему

Когда использовать паттерн синглтон?

Практически в любом приложении возникает необходимость в глобальных переменных или объектах с ограниченным числом экземпляров. Самый простой способ решить эту задачу — создать глобальный объект, который будет доступен из любой точки приложения. По своему определению синглтон гарантирует, что у некоего класса есть лишь один экземпляр. В некоторых случаях анализ предметной области строго требует, чтобы класс существовал лишь в одном экземпляре. Однако на практике паттерн «Синглтон» обычно используется для обеспечения доступа к какому-либо ресурсу, который требуется разным частям приложения.

UML схема паттерна "синглтон":

Реализация шаблона "синглтон" на C#

public sealed class Singleton
{
   private static volatile Singleton instance;
   private static object syncRoot = new Object();

   private Singleton() {}

   public static Singleton Instance
   {
      get 
      {
         if (instance == null) 
         {
            lock (syncRoot) 
            {
               if (instance == null) 
                  instance = new Singleton();
            }
         }

         return instance;
      }
   }
}

Singleton vs. Static Class

Альтернативой паттерну «Синглтон» в объектно-ориентированном мире является использование класса с исключительно статическими членами. Синглтон явно обладает большей гибкостью, но статическими функциями проще пользоваться. Какой же из двух подходов выбрать? Можно предложить следующее эмпирическое правило: при отсутствии состояния и наличии небольшого числа операций статические методы являются более подходящим решением. Если же глобальный объект обладает состоянием, то реализация на основе паттерна «Синглтон» будет проще. Существует компромиссное решение: статический класс с небольшим набором методов может выполнять роль фасада над реализацией на основе синглтона. ThreadPool.QueueUserWorkItem является хорошим примером такого подхода.

Применимость: паттерн или антипаттерн

1. Синглтон без видимого состояния - Нет ничего критического использовании синглтона, через который можно получить доступ к стабильной справочной информации или некоторым утилитам.
2. Настраиваемый контекст. Аналогично нет ничего критического в протаскивании инфраструктурных зависимостей в виде Ambient Context, то есть в использовании синглтона, возвращающего абстрактный класс или интерфейс, который можно установить в начале приложения или при инициализации юнит-теста.
3. Минимальная область использования. Ограничьте использование синглтона минимальным числом классов/модулей. Чем меньше у синглтона прямых пользователей, тем легче будет от него избавиться и перейти на более продуманную модель управления зависимостями. Помните, что чем больше у классов поль- зователей, тем сложнее его изменить. Если уж вы вынуждены использовать синглтон, возвращающий бизнес-объект, то пусть лишь несколько высокоуровневых классов-медиаторов используют синглтоны напрямую и передают его экземпляр в качестве зависимостей классам более низкого уровня.
4. Сделайте использование синглтона явным. Если передать зависимость через аргументы конструктора не удается, то сделайте использование синглтона явным. Вместо обращения к синглтону из нескольких методов сделайте статическую переменную и проинициализируйте ее экземпляром синглтона.