Есть ли жизнеспособные альтернативы шаблону GOF Singleton?

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

Я не избегаю паттерна Singleton. Либо это уместно, и я им пользуюсь, либо не уместно, и я им не пользуюсь. Я считаю, что это так просто.

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

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

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

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

(хотя я бы сказал, что это неправильный способ использования синглтона в первую очередь)

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

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

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

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

Кстати, у меня лично нет проблем с синглетонами, и я не могу понять проблемы, которые есть у других людей в отношении синглтонов. Я не вижу в них ничего плохого. То есть, если вы ими не злоупотребляете. Любой полезной техникой можно злоупотреблять, а злоупотребление приведет к отрицательным результатам. Другой метод, которым часто злоупотребляют, - это наследование. Тем не менее, никто не скажет, что наследование - это что-то плохое только потому, что некоторые люди ужасно злоупотребляют им.

Алекс Миллер в "Узоры, которые я ненавижу" цитирует следующее:

"Когда синглтон кажется ответом, я считаю, что часто разумнее:

1. Создайте интерфейс и реализацию вашего синглтона по умолчанию
2. Создайте единственный экземпляр вашей реализации по умолчанию на «вершине» вашей системы. Это может быть конфигурация Spring, или код, или определенный различными способами в зависимости от вашей системы.
3. Передайте единственный экземпляр каждому компоненту, который в нем нуждается (внедрение зависимостей)

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

Что ты имеешь в виду, как я могу этого избежать?

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

Но нет. Мне не нужно избегать одноэлементного шаблона. Этого просто не возникает.

Я думаю, что лучшее место для контроля синглтона - это уровень дизайна класса. На этом этапе вы должны иметь возможность наметить взаимодействия между классами и увидеть, действительно ли что-то определенно требует, чтобы только 1 экземпляр этого класса когда-либо существовал в любой момент жизни приложения.

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

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

Я использую синглтон в основном как «контейнер методов», без какого-либо состояния. Если мне нужно поделиться этими методами со многими классами и я хочу избежать бремени создания экземпляров и инициализации, я создаю контекст / сеанс и инициализирую там все классы; все, что относится к сеансу, также имеет доступ к содержащемуся в нем «синглтону».

Шаблон одиночка существует, потому что бывают ситуации, когда один объект необходим для предоставления набора услуг.

Даже если это так, я все же считаю подход создания одиночных экземпляров с использованием глобальное статическое поле / свойство, представляющего экземпляр, неуместным. Это неуместно, потому что создает зависимость в коде между статическим полем и объектом, а не услугами, которые предоставляет объект.

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

*pseudocode* currentContainer.GetServiceByObjectType(singletonType)
//Under the covers the object might be a singleton, but this is hidden to the consumer.

вместо единого глобального

*pseudocode* singletonType.Instance

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

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

Я считаю, что Спрятать по возможности использует одноэлементный шаблон, потому что его не всегда можно или желательно избежать.

Лучшее решение, с которым я столкнулся, - это использование фабричного шаблона для создания экземпляров ваших классов. Используя шаблон, вы можете гарантировать, что существует только один экземпляр класса, который используется совместно используемыми объектами.

Я, хотя это было бы сложно управлять, но после прочтения этого сообщения в блоге "Куда делись все синглтоны?" это кажется таким естественным. Кроме того, это очень помогает изолировать ваши модульные тесты.

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

class NeedyClass {

    private ExSingletonClass exSingleton;

    public NeedyClass(ExSingletonClass exSingleton){
        this.exSingleton = exSingleton;
    }

    // Here goes some code that uses the exSingleton object
}

А потом фабрика.

class FactoryOfNeedy {

    private ExSingletonClass exSingleton;

    public FactoryOfNeedy() {
        this.exSingleton = new ExSingletonClass();
    }

    public NeedyClass buildNeedy() {
        return new NeedyClass(this.exSingleton);
    }
}

Поскольку вы создадите экземпляр своей фабрики только один раз, будет единственный экземпляр exSingleton. Каждый раз, когда вы вызываете buildNeedy, новый экземпляр NeedyClass будет связан с exSingleton.

Надеюсь, это поможет. Пожалуйста, отметьте любые ошибки.

Чтобы понять правильный способ обхода синглтонов, вам нужно понять, что не так с синглетонами (и глобальным состоянием в целом):

Синглтоны скрывают зависимости.

Почему это важно?

Потому что Если вы скрываете зависимости, вы теряете из виду степень связи.

Вы можете возразить, что

void purchaseLaptop(String creditCardNumber, int price){
  CreditCardProcessor.getInstance().debit(creditCardNumber, amount);
  Cart.getInstance().addLaptop();
}

проще чем

void purchaseLaptop(CreditCardProcessor creditCardProcessor, Cart cart, 
                    String creditCardNumber, int price){
  creditCardProcessor.debit(creditCardNumber, amount);
  cart.addLaptop();
}

но, по крайней мере, второй API дает понять, кто именно соавторы метода.

Таким образом, способ обхода синглтонов заключается не в использовании статических переменных или локаторов служб, а в преобразовании синглтонов-классов в экземпляры, которые создаются в той области, где они имеют смысл, и внедряются в компоненты и методы, которые в них нуждаются. Вы можете использовать IoC-framework, чтобы справиться с этим, или вы можете сделать это вручную, но важно избавиться от вашего глобального состояния и сделать зависимости и взаимодействие явными.

Я не занимался программированием в объектно-ориентированной среде (например, Java), поэтому я не совсем разбираюсь в тонкостях обсуждения. Но я реализовал синглтон в PHP 4. Я сделал это как способ создания обработчика базы данных «черного ящика», который автоматически инициализируется и не должен передавать вызовы функций вверх и вниз в неполной и несколько сломанной структуре.

Прочитав несколько ссылок на шаблоны синглтонов, я не совсем уверен, что реализовал бы это точно так же снова. Что действительно было нужно, так это несколько объектов с общим хранилищем (например, фактический дескриптор базы данных), и это практически то, во что превратился мой вызов.

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

Monostate (описанный в книге Роберта Мартина «Гибкая разработка программного обеспечения») является альтернативой singleton. В этом шаблоне все данные класса статичны, но геттеры / сеттеры нестатичны.

Например:

public class MonoStateExample
{
    private static int x;

    public int getX()
    {
        return x;
    }

    public void setX(int xVal)
    {
        x = xVal;
    }
}

public class MonoDriver
{
    public static void main(String args[])
    {
        MonoStateExample m1 = new MonoStateExample();
        m1.setX(10);

        MonoStateExample m2 = new MonoStateExample();
        if (m1.getX() == m2.getX())
        {
            //singleton behavior
        }
    }
}

Monostate имеет поведение, подобное синглтону, но делает это таким образом, что программист не обязательно осознает тот факт, что используется синглтон.