1. Вау, оказывается и переменные можно вне пакета создавать - буду иметь ввиду
2. Если SingletonInstance не реализует никакого внешнедоступного интерфейса, то Вы уничтожили одно преимущество синглтона по сравнению со статическим классом:
Его теперь нельзя передавать в качестве параметра
(правда, что мешает сделать SingletonInstance публичным, а не пихать вместе с функцией, так ведь?)
3. Вообще да, использовать глобальную функцию вместо статической - прикольно
Цитата:
|
Если это реальный синглтон, то он должен защищаться от попыток создать экземпляр.
|
Описание "реального", канонического синглтона у GoF - это один из самых вредных текстов для чтнения начинающими. Они сами уже сомневаются, стоило ли его включать в книжку.
Ну вот посудите сами:
Нам нужен глобальный доступ к сервису, мы решаем забить на проблемы глобальности и сделать статическую точку доступа, но чего ради мы должны:
- ограничивать число экземпляров класса
- добавлять код, отвечающий за создание объектов в сам класс
А ведь делают синглтоном обязательно, а потом, когда требуется второй сервис вместо добавления ещё одного метода getSecondInstance() лепят переключатель isSecondMode() и кучу условной логики в сам синглтон, а потом надеются что 2 состояния внутри синглтона не будут запрошены одновременно. И я такое видел. Вот от чего здесь спасла защита от создания 2-го экземляра интересно? От экономии времени, от _не_появления багов?
Хватит уже цитировать книжки, там много чего пишут.