Комментарии 25
Вам никто еще не говорил, что singleton давно считается антипаттерном? В интернете, по-моему, про это уже на каждом заборе написано.
про это уже на каждом заборе написано
И ценность этого примерно та же, что и у заборной писанины. Стейтлесс-синглтоны - основа архитектуры целой кучи популярных бэкенд фремворков. Мне вот может кто-то объяснить, чем станут лучше Spring или Vert.x, если из них убрать синглтоны? Антипаттерном как правило являются попытки писать синглтон руками вместо того, чтобы использовать проверенные решения.
Тогда вместо борьбы стоит возглавлять. :) Например, выделить реализацию синглтона в отдельный обобщённый класс. Или базовый с ручным инстанцированием в языках без генериков.
Т.е. весь рабочий код сосредоточен в обычном классе, который оказывается лишь доступен через контейнер-одиночки. Это решило бы часть претензий к шаблону.
Класс, реализующий полезную работу можно было бы создавать отдельно в тестовом окружении.
Для тестирования кода, зависящего от одиночки - подсовывать mock-обхект.
А вам еще никто не говорил, почему он считается антипаттерном но и паттерном одновременно?
А автор, меж тем, прекрасно это объяснил и привел границы применимости.
Проблемы, возникающие при массированном использовании синглтонов, конечно реальны, но и преимущества более чем реальны.
И во множестве библиотек прекрасно используются надежные и простые синглтоны.
Ну и DI контейнеры и сервис локаторы, решающие эти проблемы, обычно являются синглтонами.
Само по себе наличие / использование глобального для приложения объекта антипаттерном не является (потому что, конечно, есть сценарии где это нужно). Антипаттерном является вариант реализации этого, который, наверное, со времен GoF гуляет по миру и теперь попал сюда с этой статьёй. Если все это делать через DI и DI-контейнер, то всё будет вполне нормально.
Вспомнился мысленный эксперимент с обезьяной, лестницей и бананами.
Одиночка! - где вы это взяли??? Я в первый раз за 21 год разработки это слышу!
Везде. Во многих местах встречал именно такой перевод.
Переводится именно так. Непонятно, как за "21 год разработки" можно было "это" услышать впервые.
Для исторического экскурса можно прочитать книжку, а для практического применения есть DI контейнеры, через которые все и делается. Никто это вручную уже сто лет не пишет.
Я начал работать разработчиком в конце 90-ых, плюс до этого обычное увлечение, три страны, десяток работодателей, но впервые слышу "одиночка" для синглтона.
https://ru.wikipedia.org/wiki/Одиночка_(шаблон_проектирования)
В переводе GoF тоже использовался термин "одиночка" - у меня сейчас нет книги под рукой, поэтому прув дать не могу, но можете поискать сами.
Впрочем вот:
Это из книжки GoF
а разве синглтоны перестают быть синглтонами если для них определить последовательность инициализации?
Это да! А еще если их проинициализировать заведомо до запуска основного кода приложения - до перехода к функции 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
Я думал речь о клиентах синглтона а не об инициализации.
Который проверяет, создан ли инстанс класса в приватном поле
Паттерн Одиночка