Подгрузка классов и использование в них данных другого класса через конструктор.

[Flyer]

Спасибо.

Но жесть получилась еще та )) ...

 Registry::get('GlobalConfig')->config->path->applicationModules

 

[Flyer]

Те пришли скажем к такому виду:

include_once (Registry::get('GlobalConfig')->config->path->applicationModules.$this->moduleName."/templates/".join('.',$this->modules).".phtml");

учитывая что в переменной конфига лежит что то типа "../application/modules", обращение к нему кажется каким то сектантно-фанатичным =)

 

[tz-lom]

а вам предлагали статические классы,но нет же,написали свою обёртку обёрток

 

[Flyer]

Ну попробовать и на своей шкуре испытать результат полезный опыт.

Не могли бы вы подробнее рассказать о предлагаемом вами варианте, а лучше показать пример простецкий?

 

[HraKK]

Я за DC

 

[AmdY]

Flyer
Registry - это чуждый php паттерн, потому что у нас есть свой костыль $GLOBALS['GlobalConfig']. так что ты променял шило на мыло. Смысл использовать данный паттер можно узнать из его постов http://tinyurl.com/2cjhy7p .

 

[grigori]

учитывая что в переменной конфига лежит что то типа "../application/modules", обращение к нему кажется каким то сектантно-фанатичным =)

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

 

[Активист]

Нет, проблем ООП в том, что нет общих принципов взаимодействия объектов, да есть паттерны, но в большой четверки предпочли абстрагироваться от кода, а обобщили, но в контексте задач и как правильно из приминать - решили умолчать.

Есть небольшие высеры некоторых авторов, но нет систематизации. Объект ведь нечто живое, имеет связи, умеет что-то делать, чего-то не умеет, что-то делает через других, типичное поведении индивида в социуме.

Если бы был стандарт - то да. Короче, вечный срач C vs С++ захватил еще и PHP

Правильный ООП код - это наличие ОТЛИЧНОЙ документации для разработчика.

 

[Духовность™]

Ты придумал Dependency Container.

правильно ли я понимаю, что DC (он же Context) - это всего навсего объект-хранилище, инициализируемый в бутстрапе, имеющий методы set/get для звездных, системных объектов. И цель этого "контейнера" - абстрагироваться в приложении от явных вызовов звездных объектов в коде и их явного инстанцирования?

Т.е. в контроллерах вместо

Request::getInstance()

мы пишем

$this->context->getRequest()

тем самым сохраняя в пределах всего приложения единый интерфейс? И теперь в случае чего мы можем заменить в $this->context инстанс request-a и безболезненно продолжать пользоваться интерфейсом $this->context->getRequest().

Правильно ли я понимаю?

 

[флоппик]

Нет. Dependency Container это объект, (который неважно где инициализируется, потому что в методологиях разработки нет никаких «бутстрапов», просто потому что пхп не единственный язык программирования) который умеет хранить и инициализировать объекты приложения, выполняя все их зависимости от других объектов, и передает запрошенный объект в контекст приложения, в котором к нему обратились.

РЕАЛИЗАЦИЯ ЭТОГО ПАТТЕРНА, КАК И БОЛЬШИНСТВА ДРУГИХ ПАТТЕРНОВ, В КОНЕЧНОМ КОДЕ МОЖЕТ БЫТЬ РАЗНОЙ.
Она зависит от языка программирования, привычек, очевидности, неважно.

В Phemto, например, достаточно сделать

$object->method(Database $database);

и $database будет инициализирован подходящим классом под интерфейс Database

 

[Духовность™]

который умеет хранить и инициализировать объекты приложения

Получается, в нем явно могут быть зашиты имена классов?

Кто-нибудь вообще может показать максимально доступный для понимания DC в рамках PHP?

 

[флоппик]

Кто-нибудь вообще может показать максимально доступный для понимания DC в рамках PHP?

http://www.procata.com/talks/phptek-may2007-dependency.pdf — хорошая презенташка на эту тему, короткая и ясная, как божий день.