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

Jon Skeet, THE_SKEET, has a great article exemplifying various ways to implement correctly (Thread safe, lazy, performant) the Singleton pattern.

Go read it here.

By popular demand (er... downvote) I reproduce the Skeet version:

public sealed class Singleton
{
    Singleton()
    {
    }

    public static Singleton Instance
    {
        get
        {
            return Nested.instance;
        }
    }

    class Nested
    {
        // Explicit static constructor to tell C# compiler
        // not to mark type as beforefieldinit
        static Nested()
        {
        }

        internal static readonly Singleton instance = new Singleton();
    }
}

Here, instantiation is triggered by the first reference to the static member of the nested class, which only occurs in Instance. This means the implementation is fully lazy, but has all the performance benefits of the previous ones. Note that although nested classes have access to the enclosing class's private members, the reverse is not true, hence the need for instance to be internal here. That doesn't raise any other problems, though, as the class itself is private. The code is a bit more complicated in order to make the instantiation lazy, however.

Предполагая, что ваш вопрос в заголовке:

Однажды я работал с COM-объектом, который мог иметь только один экземпляр на сервер. Мы представили его всему приложению ASP.NET через синглтон.

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

По моему опыту, я использовал синглтоны где объект собирался использовать много раз в течение срока службы приложения, требовал инициализации и / или занимал много памяти.

Вы должны использовать Singleton, когда должен быть только один экземпляр объекта. Однако у Миско Хевери есть некоторые мысли о том, почему синглтоны плохие!

Обратите внимание, что этот код не является потокобезопасным:

get   
{
   if (instance == null)   
      instance = new Singleton();   
    return instance;   
}   

Один поток может войти в функцию, пройти тест для ноль, а затем будет приостановлено. Затем можно запустить второй поток и пройти нулевой тест. С этого момента оба потока в какой-то момент создадут свою собственную копию объекта sungleton, только один из которых будет использован.

Это может не иметь большого значения в языке GC, таком как C #, но если синглтон контролирует ресурсы других источников. чем память, то это имеет значение. Вам нужно использовать дважды проверенный шаблон блокировки , чтобы предотвратить его.

Простой. Что делает синглтон?

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

вы используете синглтон, когда вам нужно обоих из этих вещей.

И это редко. Глобалы вообще говоря, плохо. Мы стараемся избегать их, когда это возможно. И построение вашего приложения на предположении, что «если существует более одного экземпляра, это ошибка», опасно, потому что вы обычно обнаруживаете, что это предположение не выполняется. Возможно, вы хотите иметь возможность создавать несколько экземпляров локально для целей кэширования. Возможно, вам требуется более одной базы данных, более одного журнала или, возможно, производительность потоков требует, чтобы вы предоставили каждому потоку свой экземпляр.

В любом случае вам не нужно применять «только один экземпляр может существовать "предположение. Если вам нужен только один экземпляр, просто создайте только один экземпляр. Но оставьте конструктор публично видимым, чтобы можно было создать больше экземпляров , если это окажется необходимым .

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

Если вам нужна одна из функций, предлагаемых синглтоном Внедрите эту функцию без другой. Если вам нужно что-то глобально доступное, сделайте это глобальным. Не синглтон. И если вам нужно обеспечить, чтобы существовал только один экземпляр (я не могу придумать каких-либо вероятных ситуаций, в которых вы хотели бы этого), то реализуйте это без глобальной наглядности.

Единственное применение синглетонов в реальном мире. Я когда-либо видел, чтобы «архитектор прочитал книгу GoF и решил повсюду втирать шаблоны проектирования», или «какой-то программист, застрявший в 80-х, не доволен всей« объектно-ориентированной »вещью и хочет кодировать процедурно, что означает хранение данных как глобальных. А одиночные звуки звучат как «ООП» способ создания глобалов без криков ».

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

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

Очевидно, вы должны обратить внимание, что поддержание этой вещи не стоит вам дороже, чем ее воссоздание каждый раз.

Один из способов, которыми я использовал синглтон, - реализовать объект «главный контроллер» для приложения. Это было немного похоже на объект Application, который вы получаете с VBA.

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