Вопросы по ООП в PHP

Коли пошла такая пьянка, то для тех кто уже знает PHP на среднем уровне и желает двигатся в сторону ОО программирования, советую Мэтт Зандстра - PHP. Объекты, шаблоны и методики программирования. Изд. 2-е (линк на depositfiles.com).
З.Ы: книжка для прочтения на ПК в формате Djvu.

AlkatraZ (15.12.2011/19:54)
Кстати, кто хочет освоить ООП (понадобится, ибо в новом двиге много где применяется), рекомендую староватые, но полезные статьи:
http://kurepin.ru/php/
Там конечно еще не описаны навороты PHP5, но б

прочитал на одном дыхании, нового в принципе ни чего не узнал, но несколько методов реализаций для себя подчерпнул, жаль автор перестал писать и удалил форум, да и без базы знаний (новичку) не прочитать, примеры для пхп4, для register_globals 1 , но в челом про классы и структуру почитать интересно

L!MP (16.12.2011/17:43)
Коли пошла такая пьянка, то для тех кто уже знает PHP на среднем уровне и желает двигатся в сторону ОО программирования, советую [url=http://depositfiles.com/files/4jw2xpbo4]Мэтт Зандстра - PHP. Объек

спасибо, щас скачаю! а то эта моби цмс не хухры-мухры, надо подготовиться

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

http://wiki.agiledev.ru/doku.p ... _code

http://wiki.agiledev.ru/doku.p ... ction

L!MP (22.12.2011/09:29)
Вот еще две, хоть и старенькие, но очень хорошие статьи посвещенные "Управлению зависимостями".
Думаю что у многих людей, начавших освоение ООП, возникают такие вопросы как - "как должны взаимодейств

Хорошие статьи.
Однако на сегодня, как я смотрел в большинстве случаев, присменяют или патерн Registry, или в самых простых фреймворках (типа KISS) глобальный массив $_GLOBALS
---
В новом проекте, я лично использовал Registry, причем его реализацию делал наподобие, как в Zend Framework, их подход мне показался наиболее гибким, хотя сам класс от того фреймворка не годился, ибо как и все универсальные, страдает излишней сложностью и перенавороченностью.

В итоге, сделан синглтон Registry, наследующий встроенный в РНР ArrayObject. там уже есть все нужные интерфейсы, типа IteratorAggregate, Traversable, ArrayAccess, Serializable, Countable, не приходится писать эти методы вручную (как я делал до этого).
Получилось и просто и функционально.

AlkatraZ, Использование Registry не всегда удобно, особенно то что при его использование необходимо зараннее "загонять" в него инстанции обьектов. Опять таки, затруднен lazy initialization, не явность содержимого.

В свое время, я не сильно раздумывая отдал предпочтение Singleton и FactoryMethod.

Все прекрасно работает, хотя сейчас, я посмотрел бы в сторону ServiceLocator'a

L!MP (22.12.2011/10:45)
AlkatraZ, Использование Registry не всегда удобно, особенно то что при его использование необходимо зараннее "загонять" в него инстанции обьектов. Опять таки, затруднен lazy initialization, не явност

Я тоже раздумывал, но все же остановился на Registry
То, что в него явным образом нужно загонять объекты, это не является большим недостатком, при Сервис локаторе код распухает немного больше и вызов классов идет не совсем привычным методом:
$registry->myclass = new MyClass(); // Вариант с Registry
lmbToolkit :: merge(new LogTools ()); // Вариант с сервис локатором

А загонять объект класса к примеру мне не всегда нужно при инициализации самого класса.
Простой пример:
В новом движке класс netHandler содержит все навороты по получению и обработке IP адерсаов, включая обработку черных (бан по IP) / белых списков и защиты от HTTP Flood атак. Чтоб не грузить систему в случае атаки, данный класс инициализируется ДО каких либо других. Если все проверки прошли, тогда инициализитуются остальная система и объект netHandler передается в Registry

AlkatraZ, Ну ты весьма сложную реализацию сервис локатора взял. Впринципе серв.локатор это реестр с явным интерфейсом (и содержимым) который может как хранить инстанции, так и отвечать за их инициализацию.

По этому, если отбросить всю шелуху с LimbToolkit связаную с композицией ("смешиванием" нескольких локаторов), то все сведется к:

class Locator {
private $request;
function setRequest(\IRequest $object) {
$this->request = $object;
}
function getRequest() {
if (is_null($this->request))
$this->request = new \Request;
return $this->request;
}

Locator::instance()->getRequest()->...

L!MP (22.12.2011/11:17)
AlkatraZ, Ну ты весьма сложную реализацию сервис локатора взял. Впринципе серв.локатор это реестр с явным интерфейсом (и содержимым) который может как хранить инстанции, так и отвечать за их инициали

Все равно длинее
В случае с реестром, если я хочу получить к примеру адрес IP,который был передан объектом netHandler я пишу всего лишь

$ip = $registry->netHandler['ip'];

Так, как мой Registry реализует интерфейс Arrayaccess, я могу обращаться как к простому массиву. А могу и как к объекту

$ip = $registry->netHandler->ip
---
А в случае с локатором, все происходит намного длинее и неочевиднее.
Хотя, иногда может пригодиться то, что он сам инициализирует объект в случае если он еще не инициализирован.

Так лучше:
$ip = $registry->netHandler->ip

а первый вариант лучше вовсе выкинуть ибо приводит лишь к путанице и выглядит не очень