Comments 25
Вам никто еще не говорил, что singleton давно считается антипаттерном? В интернете, по-моему, про это уже на каждом заборе написано.
про это уже на каждом заборе написано
И ценность этого примерно та же, что и у заборной писанины. Стейтлесс-синглтоны - основа архитектуры целой кучи популярных бэкенд фремворков. Мне вот может кто-то объяснить, чем станут лучше Spring или Vert.x, если из них убрать синглтоны? Антипаттерном как правило являются попытки писать синглтон руками вместо того, чтобы использовать проверенные решения.
Тогда вместо борьбы стоит возглавлять. :) Например, выделить реализацию синглтона в отдельный обобщённый класс. Или базовый с ручным инстанцированием в языках без генериков.
Т.е. весь рабочий код сосредоточен в обычном классе, который оказывается лишь доступен через контейнер-одиночки. Это решило бы часть претензий к шаблону.
Класс, реализующий полезную работу можно было бы создавать отдельно в тестовом окружении.
Для тестирования кода, зависящего от одиночки - подсовывать mock-обхект.
А вам еще никто не говорил, почему он считается антипаттерном но и паттерном одновременно?
А автор, меж тем, прекрасно это объяснил и привел границы применимости.
Проблемы, возникающие при массированном использовании синглтонов, конечно реальны, но и преимущества более чем реальны.
И во множестве библиотек прекрасно используются надежные и простые синглтоны.
Ну и DI контейнеры и сервис локаторы, решающие эти проблемы, обычно являются синглтонами.
Само по себе наличие / использование глобального для приложения объекта антипаттерном не является (потому что, конечно, есть сценарии где это нужно). Антипаттерном является вариант реализации этого, который, наверное, со времен GoF гуляет по миру и теперь попал сюда с этой статьёй. Если все это делать через DI и DI-контейнер, то всё будет вполне нормально.
Вспомнился мысленный эксперимент с обезьяной, лестницей и бананами.
Одиночка! - где вы это взяли??? Я в первый раз за 21 год разработки это слышу!
Для исторического экскурса можно прочитать книжку, а для практического применения есть DI контейнеры, через которые все и делается. Никто это вручную уже сто лет не пишет.
Я начал работать разработчиком в конце 90-ых, плюс до этого обычное увлечение, три страны, десяток работодателей, но впервые слышу "одиночка" для синглтона.
https://ru.wikipedia.org/wiki/Одиночка_(шаблон_проектирования)
В переводе GoF тоже использовался термин "одиночка" - у меня сейчас нет книги под рукой, поэтому прув дать не могу, но можете поискать сами.
Впрочем вот:
Это из книжки GoF
Помню как перед отдачей игры издателю убирал сингтоны и просто последовательно инициализировал сущности. Потому что начиная с определенной сложности от непредсказуемой последовательности инициализации слишком много проблем возникало.
а разве синглтоны перестают быть синглтонами если для них определить последовательность инициализации?
Не перестают, но синглтон это автоматически плюс один if при каждом обращении к объекту. Если проинициализировать объекты самому, то все эти if-ы можно убрать.
Это да! А еще если их проинициализировать заведомо до запуска основного кода приложения - до перехода к функции MAIN(), ну и в правильном порядке как вы и написали,то и не придется статью каждый месяц новую писать про синглтоны и их потокобезапасность и т. д. и т. п.
В связи с этим у меня вопрос, почему лучшие умы не рассмотрят такую возможность?
Есть много других более сложных и поэтому более интересных паттернов проектирования. Почему постоянно надо писать про один и то же, причем самый простой?
Простите, а какой if ?
Который проверяет, существует ли уже объект к которому идет обращение
можно же через холдер cделать
public class SingletonImpl {
private static class Holder {
private static final SingletonImpl HOLDER_INSTANCE = new SingletonImpl();
}
public static SingletonImpl getInstance() {
return Holder.HOLDER_INSTANCE;
}
private SingletonImpl() {}
public void doSomething() {}
}
Ok
Я думал речь о клиентах синглтона а не об инициализации.
Который проверяет, создан ли инстанс класса в приватном поле
Паттерн Одиночка