Singleton и static class

Question

Вот решил посмотреть, что за чудо такое этот Singleton. И сразу возник вопрос: а чем он лучше статик класса? От статик класса объекты нельзя сделать, да и наследоваться от него тоже нельзя.
И вообще какова область применения синглтона?
В многопоточном приложении будут возникать проблемы при использовании статик класса?

Вот, к примеру два одинаковых класса, но реализованных в виде синглтона и статик:

public sealed class MyMathSingleton
{
    private static readonly Object obj_lock = new Object();
    private static MyMathSingleton instance = null;

    private MyMathSingleton()
    { }

    public static MyMathSingleton Instance
    {
        get
        {
            if (instance != null) return instance;
            Monitor.Enter(obj_lock);
            Interlocked.Exchange(ref instance, new MyMathSingleton());
            Monitor.Exit(obj_lock);
            return instance;                
        }
    }

    public int A_plus_B(int a, int b)
    { return a + b; }
}

public static class MyMathStatic
{
    public static int A_plus_B(int a, int b)
    { return a + b; }
}  

PS. реализацию синглтона взял отсюда: Три возраста паттерна Singleton. Правда там автор пишет, что создание инстанса должно выглядеть так, иначе чуда не произойдет:

Singleton temp = new Singleton();
Interlocked.Exchange(ref instance, temp);   

А у меня такая запись вполне нормально кушается компилятором:

Interlocked.Exchange(ref instance, new MyMathSingleton());  

---

UPD 14.05.27

Допустим у меня в приложении есть форма, с помощью которой в одну из таблиц БД заносится новая запись или же запись редактируется. Эта форма мне нужна только одна, скажу больше - если их будет несколько, то могут возникнуть проблемы при редактировании записи. В данном случае целесообразно реализовать класс формы в виде синглтона?

Answer 1

Re: ваш PS

Автор статьи на Хабре самоуверенно порет чушь.

Начнём с главного: его код синглтона не потокобезопасен! Разбор:

if(instance != null) return instance;
// (*)
Monitor.Enter(s_lock);
Singleton temp = new Singleton();
Interlocked.Exchange(ref instance, temp);
Monitor.Exit(s_lock);
return instance;

Пусть поток 1 начинает выполнять приведённый код. instance в этот момент есть null, так что первая проверка проходит, и выполнение доходит до строки (*).

Пусть в этот момент произойдёт переключение контекста (это ведь возможно, правильно?), и начинает выполняться второй поток. Он точно так же проверяет instance, проходит начальную проверку, пробегает через (*), получает lock, создаёт экземпляр синглтона, записывает его в instance, отпускает lock и выходит. Второй поток получает ссылку на instance только что созданного синглтона.

Теперь управление получает первый поток. Он точно так же получает lock, создаёт второй экземпляр синглтона, записывает его в instance, затирая старое значение, отпускает lock и выходит. Первый поток получает ссылку на другой объект.

Катастрофа.

Теперь по мелочам. Разработчики .NET не просто так сделали lock(obj) синонимом Monitor.Enter(obj, ref lockTaken), а не просто Monitor.Enter(obj). Вариант с Monitor.Enter(obj) работает неправильно в случае, если возможны исключения. Поэтому замена lock на явный Monitor.Enter — ухудшение.

Ещё большее ухудшение — отказ от try/catch. Без базара, без try/catch быстрее, только код получается неправильный. (Впрочем, если правильный код нам не нужен, без lock'а было бы ещё быстрее.) Если по каким-то причинам конструктор Singleton'а выбросит исключение (а это может быть не только деление на 0, но и TypeLoadException, например), то s_lock останется залоченным навсегда — deadlock.

Затем, автор критикует правильные, рекомендованные экспертами (а Jon Skeet — мегаэксперт) имплементации под совершенно надуманными предлогами. По поводу подхода «через readonly поле» автор пишет:

Конструктор может быть только статичным. Это особенность компилятора — если конструткор не статичен, то тип будет помечен как beforefieldinit и readonly создадутся одновременно со static-ами.

Это фактически неверно, автор судя по всему просто не понял, что именно написал Jon. У синглтона есть нестатический конструктор, просто явный статический конструктор должен присутствовать. Между «статический конструктор должен присутствовать» и «конструктор может быть только статичным» огромная разница.

Правильная, остроумная, каноническая реализация синглтона с вложенным классом удостоилась лишь замечания «Недостатки у него те же самые, что у любого другого кода, который использует nested-классы». Мне неизвестны недостатки вызванные одним лишь наличием вложенных классов. Если мне кто-либо сообщит, готов изменить своё мнение.

Наконец, самое концептуально верное решение с Lazy<T> критикуется за то, что оно «не работает с потоками», а используют структуры языка, которые «обманывают интерпретатор». Здесь неверно вообще всё, кроме союзов и предлогов. Начнём с того, что C# — компилируемый язык, интерпретатора C# не существует. Затем, никакого обмана нет: Lazy<T> работает строго как обещает его документация. То, что его поведение отличается от поведения других классов — не обман и не трюк. При желании то же самое можно заимплементировать самому вручную.

Затем, правильным при реализации синглтона является не многопоточность или прочие технические мелочи, а простой инвариант: как бы синглтон не использовался, всегда гарантировано наличие не более одного экземпляра синглтона на AppDomain. Именно это гарантируется классом Lazy<T>. Используются ли при этом специальные механизмы для поддержки многопоточности или свойства языка, никому не интересно. Главное — чтобы семантика единственного экземпляра была выдержана. Именно это гарантирует класс Lazy<T>, абстрагируя нас от деталей реализации. И именно поэтому такая имплементация — самая правильная.

Вывод: не все статьи на Хабре одинаково полезны.

Answer 2

Он не лучше и не хуже статического класса, у них предназначение совершенно разное. Статический класс - это по сути пространство имен для функций/констант/etc. Синглтон - это сущность, которая может существовать в одном экземпляре. То есть как говорится, "все совпадения случайны". Задача синглтона - это гарантия существования только одного экземпляра с учетом многопоточности (без таковой он становится дыркой от бублика), тогда как статический класс по сути можно считать синтаксическим сахаром - C# полностью объектно-ориентирован, а потому наличие "самостоятельных" функций/переменных/констант, не заключенных в класс, в нем не допускается. Эту проблему достаточно элегантно решают статические классы. Ну а тот факт, что и для того и другого невозможно создание экземпляров (точнее, для синглтона возможно, но не напрямую) и от обоих нельзя наследоваться - это всего лишь похожие следствия из двух разных идей.

Приведенный вами пример со статическим классом мягко говоря не в тему - он не предоставляет никакого экземпляра "в единственном числе", как раз-таки являясь "неймспейсом для функции". А потому отождествлять его с синглтоном некорректно - пропадает весь смысл идеи. Примерно то же самое можно сказать и про сам синглтон из вашего примера - вариант, предложенный Рихтером, вы дополнили ненужным методом A_plus_B (он не имеет отношения к самой идее и не влияет на "одиночность"). Собственно, еще стоит упомянуть, что синглтон, как паттерн проектирования - сущность не имеющая непосредственного отношения к конкретному языку, а статический класс - это всего лишь особенность ряда языков, в том числе и C#.

Answer 3

Стоит добавить пару слов про тестирование.

class IdentityService : IIdentityService
{
    private IDataService _dataService;
public IdentityService(IDataService dataService)
{
   // IDataService, естественно, интерфейс
   _dataService = dataService;
   ...
}

}

Довольно часто синглтон представляет какую-либо составную часть большой системы, т. е. является как-бы слоем или узлом. Так, например, IdentityService отвечает за аутентификацию/авторизацию пользователей. В то же время, IdentityService зависит от другого сервиса-синглтона IDataService (в принципе, IdentityService не знает, что IDataService синглтон (он может им и не являться, это только для примера)).

Здесь как раз и видно "преимущество" синглтонов перед статиками - мы в любой можем подменить передаваемую в конструктор реализацию IDataService так, что это никак не повлияет на работу IdentityService. И так, если нам нужно будет написать юнит-тесты к IdentityService, то мы просто подменим IDataService на какой-нибудь FakeDataService с методами-заглушками. Собственно, это уже принципы Dependency Injection.

---

Кстати, обычно временем жизни экземпляров занимаются специальные IoC-контейнеры, т. е. при инициализации приложения вы просто указываете какой сервис сколько должен жить.