Синглетоны

[metaclass]

https://github.com/SparkViewEngine/spark/blob/master/src/Samples/DirectUsage/ConsoleTemplating/Services/MessageBuilder.cs

А вот насколько подобный код (статик _instance и его инициализация) является кошерным? Ну с interlocked все более-менее понятно, а вот собственно использование синглетонов вместо всяких модных IoC и тому подобного усложняющего все трэша?

Comments

[metaclass.livejournal.com]

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

[vp.livejournal.com]

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

[permea-kra.livejournal.com]

>Например, логгер, он может быть архитектурно один на все приложение.

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

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

[vp.livejournal.com]

При нормальной архитектуре нет никаких проблем, допустим, через параметры конструкторов классов передавать нужные экземпляры классов. Но с другой стороны это может загромождать инициализацию, когда тебе нужно передать n+1 разных контекстов, без которых никак. :)

[permea-kra.livejournal.com]

В указанной ситуации вполне можно использовать фабрики классов, в которые можно положить n+m контекстов заранее.

[metaclass.livejournal.com]

Ад паттернов. :)

[permea-kra.livejournal.com]

Переходите на хаскель =).

[vp.livejournal.com]

Имхо наименее симпатичное из решений.

[permea-kra.livejournal.com]

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

[vp.livejournal.com]

А в какой момент вы предлагаете доставать мой контекст из общей фабрики? До вызова конструктора, затем передавая его в конструктор, или в самом конструкторе?
И что будет ключом в том и ином случае?

[metaclass.livejournal.com]

Причем тут ключ воще? Фабрика это условно говоря класс с десятком полей ссылающихся на куски контекста и одним методом типа "CreateЧегоНибудь" вызывающим конструктор с передачей в него контекстов.
Меня этот вариант тащемта напрягает адом паттернов, написанием классов ради того чтобы писать классы.

[permea-kra.livejournal.com]

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

[permea-kra.livejournal.com]

В описанной ситуации я бы таскал в объекте ссылку на фабрику, переданную в конструкторе.

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