Singletone + Reflection + PHP 5.3

igortik

Новичок
MiksIr
Спасибо, прислушаюсь, подумаю.

С DI ясно, не исключаю метода inject там, где он нужен, чтобы улучшить читабельность кода и расширить возможности замены и т.п.
Но все равно не могу понять почему Singletone так ругают.

В контексте разбора, например, URI, что здесь плохого. Один объект, одни данные, глобальный доступ.
Я разделяю мнение на счет необходимости DI, но что мешает делать инъекцию инстанцированным объектом?
Решается проблема видимости того, что использует Класс и ему передается единственная ссылка на инстанцированный объект.

Не понимаю я, чем Синглтон плох, прочел всю тему http://phpclub.ru/talk/threads/Почему-singelton-плохая-практика.66181/page-5
 

MiksIr

miksir@home:~$
но что мешает делать инъекцию инстанцированным объектом
Это зачем вообще? У вас есть код, который создает нужные объекты и инжектирует их. Зачем их создавать через синглтон?
Вот, я как-то натыкался, ща с гуглем пополам нашел эту ссылку http://misko.hevery.com/code-reviewers-guide/
Там в общем то, о чем я говорю, в частности по Синглтонам целый раздел. Ну и некоторые записи в блоге там тоже интересные.
 

igortik

Новичок
В общем, они предлагают отойти от идеи Глобального хранения данных (реестры, локаторы и т.п.), не применять статических функций и методов, а применять повсеместно DI.
Может это у них стиль такой (рамки, установленные правила проектирования внутри компании)?

В итоге для себя понимаю одно: все сводится к TDD и более вменяемых причин отойти от Singletone, Service Locator, Registry - НЕТ ? :/
 

A1x

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

igortik

Новичок
конечно использовать DI наиболее правильно, но если это по каким-то причинам невозможно (например лень), то можно использовать синглтон,
но не такой навороченый как в стартовом посте (лучше уж DI), а старый добрый синглтон, тот что пишется в три строчки
постепенно начинаю соглашаться ... соглашаюсь неохотно, но верю почему-то в TDD.
Хотя без него много лет жили и не всегда TDD оправдан в условиях граничных бюджетов особенно. ИМХО.

Будем смотреть в сторону DI.
Мой пример в первом посте меня тоже не совсем устраивал по причинам перечисленных минусов.
 

MiksIr

miksir@home:~$
Ну, скажем, TDD - это крайняя степень, так сказать полное просветление. Тесты можно писать и уже на написанные классы, хотя, конечно, это в 90% будет... м... далеко не 100% покрытие ;) Но как шаг из темноты в TDD - сойдет. ИМХО.
Тестирование - основное, да. Но кроме этого еще переносимость классов. При использовании реестров как минимум придется таскать за собой еще и класс реестра, который может быть весьма толстым. И, как в случае с реестром/тулкитом, так в случае и синглтоном - очень сложно будет понять, что именно нужно тащить, т.е. придется изучать код класса, что бы понять, что он хочет, тогда как DI преподносит это на открытой ладони.
 

igortik

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

Итог напрашивается сам - все зависит от архитектуры.
Ко как-то разделение и сведение к 0 зависимостей становится более по душе :)
 
Сверху