Нормальная ли реализация синглтона?

[pas.delger]

Добрый день!

Родилась в голове идея реализации синглтона через замыкание, возвращающее его инстанс описанный рядом. Вся логика, разумеется, в инстансе.


package {

public function get Singleton():SingletonInstance{
if (!instance) instance = new SingletonInstance;

return instance;
}

}

var instance:SingletonInstance;

class SingletonInstance {

public function sayHello():void{
trace("Hello from singleton");
}

}


Таким образом можно красиво обратиться:

Singleton.sayHello()

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

Спасибо!

[maxkar]

А чем вам статические методы не угодили, зачем вам singleton? Вопрос, конечно, провокационный, но позволяет задуматься, нужен вам singleton, набор методов или Dependency injection container.

[a_[w]]

Вводит в заблуждение, как использовать типизацию по отношению к Singleton?
Интуитивно если класс, то var object:Class, а если экземпляр, то var object:Singleton.
var instance:* = new Singleton.constructor();
Если это реальный синглтон, то он должен защищаться от попыток создать экземпляр.

[expl]

1. Вау, оказывается и переменные можно вне пакета создавать - буду иметь ввиду
2. Если SingletonInstance не реализует никакого внешнедоступного интерфейса, то Вы уничтожили одно преимущество синглтона по сравнению со статическим классом:
Его теперь нельзя передавать в качестве параметра
(правда, что мешает сделать SingletonInstance публичным, а не пихать вместе с функцией, так ведь?)
3. Вообще да, использовать глобальную функцию вместо статической - прикольно :)

Если это реальный синглтон, то он должен защищаться от попыток создать экземпляр.
Описание "реального", канонического синглтона у GoF - это один из самых вредных текстов для чтнения начинающими. Они сами уже сомневаются, стоило ли его включать в книжку.
Ну вот посудите сами:

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

А ведь делают синглтоном обязательно, а потом, когда требуется второй сервис вместо добавления ещё одного метода getSecondInstance() лепят переключатель isSecondMode() и кучу условной логики в сам синглтон, а потом надеются что 2 состояния внутри синглтона не будут запрошены одновременно. И я такое видел. Вот от чего здесь спасла защита от создания 2-го экземляра интересно? От экономии времени, от _не_появления багов?
Хватит уже цитировать книжки, там много чего пишут.

[a_[w]]

expl, тема звучит так "реализация синглтона" -- разница между точкой доступа и паттерном "синглтон" есть. Если текст о вреде синглтонов для меня, то не стоит заморачиваться -- я не использую их.


Подумал и появился вопрос -- можно ли как-то извне получить доступ к переменной?

[expl]

expl, тема звучит так "реализация синглтона" -- разница между точкой доступа и паттерном "синглтон" есть.
Терминологически, конечно, Вы правы, просто не сдержался, в большинстве ведь случаев эта "защита" только делает хуже
Кстати здесь автор таки её реализовал в полном обёме - синглтон снаружи второй раз не создать никак (ценой невозможности передачи в качестве параметра). ИМХО оно не надо было - я за всю историю на типичной as3-шной реализации словил исключение создания второго экземпляра 2 раза, а проблем с невозможностью создать второй и трудностями наследования из-за этих хитрых защит - получал неоднократно.
Хотя последнее время стало полегче - коллеги вроде "научились" обходится без этого паттерна/антипаттерна (в последних проектах их насчитывается единицы на несколько сотен "нормальных" классов)

[pas.delger]

Вердикт - ну его в баню вообще этот синглтон. (:

На самом деле, как я понимаю, ведь простота обращения к синглтону - достоинство куда важнее чем защита от повторного создания и прочего. Отсюда в общем-то и родилась идея попробовать такой подход, через функцию. Максимально отделить логику объекта от функционала передачи доступа к нему. Что б красиво было (: Пусть за это отвечает абсолютно обособленный сервис.

[expl]

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

Функцию отдельно - класс отдельно - и будет нормально, только защита от пересоздания будет не такой антиидиотской/пулинепробиваемой.

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