синглтоны

[juan_gandhi]

Как-то я не врубался во вред синглтонов - пока не пришлось рефакторить одну и ту же апликацию, разнесённую по двум платформам методом копи-пейста. Всякая собака ссылается на синглтон. Будто нельзя в параметрах получить (di, т.е.)

Так я о чём? Да вот: синглтон класса - это примерно как поименованная общая область. Вот вам имя, вот вам инстанс, и делайте вы с этим что хотите.

Тьфу.

Так что осознал, да. Синглтоны не то что зло, а большая глупость, имеющая причиной отсутствие дизайна. Десяток синглтонов - и вот вам помойка. В добавок к которой возникает священное знание: чтобы сделать то-то и то-то, надо взять три таких-то синглтона (и передать их друг другу, во).

Comments

[gabaidulin.livejournal.com]

Вот конкретно про php напишу.

Разумеется я читал про DI и про IoC. Но "тащить" подобный контейнер или делать service locator мне не нравится по нескольим причинам.

1. Код становится менее читаемым.
2. Для php нету устоявшейся практики применения IoC и вообще я сомневаюсь, что есть грамотные имплементации. Например порт pico выглядит ужасно, синтаксис конфигурации ужасен.
3. Производительность. Reflection все еще очень медленный на php(в особенности "new" Reflection API).

Мы использовали подход, что все служебные вещи(типа singltone, abstract factory, accert и так далее) это как бы часть языка. У нас был хороший framework, в котором мы все это хорошо реализовали.

Программист, который садился писать приложение, писал его фактически не на php, а на onPHP :-)

То есть если ему нужен был класс, который инстанциируется лишь однажды на все приложение, то он просто наследовался от abstract singleton.

Вы ведь не используете DI для внутренних классов языка или библиотеки.

Конкретно с сессией пример.

Имплементация сессии врядли меняется в php.

То есть вы пишите класс SessionUtils например. Его методы будут обычными врапперами для session_* и все. Считайте этот класс частью языка.

С контроллерами тоже все просто. Если мы говорим про web, то на входе контроллера будет HttpReqeust. Он заполнется глобальными данными из _GET/_POST/_SESSION в Front Controller (если это MVC).

То есть мой поинт в том, что сложные IoC контейнеры и не нужны вовсе.
Для реализации обычно хватает DI через конструктор или сеттер.

[gabaidulin.livejournal.com]

Да, про java. Сейчас как раз изучаю J2EE и в частности spring. Там подход как раз обратный.

Практически все аспекты связанные с сущностями и их связями в вашем приложении предлагается описывать с помощью конфигурационных файлов, которые потом использует местный IoC контейнер. Впрочем можно использовать и императивный стиль, вместо конфигов. Не в этом дело. Также используется AOP.

Но в java, с моей точки зрения, этот подход более оправдан, потому что java строится на jcp, а он в свою очередь состоит из небольших спецификаций. И для каждой из них есть по несколько распрастраненных имплементаций. Поэтому здесь нужна максимальная гибкость и слабосвязность компонентов и сервисов.

Но такой подход сложнее.

[fantaseour.livejournal.com]

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

И автор, известный в общем-то -- Маркус Бейкер (aka lastcraft)

[gabaidulin.livejournal.com]

Да, phemto выглядит получше, но когда я ковырял эту тему(начало 2007 вроде), то phemto не видел(не было?).

Но, привеликой разницы, писать ли:

...new Reusable(new Object))...

Object extends Singleton

применительно к топику я не вижу, кроме того, что вторая запись более простая. А в целом да, IoC - это скорее добро.