Форум PHP

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

Итак..... Все члены и методы класса (наверно кроме конструтокра) объявляем Private или protected....

class myclass{
private $param=false;
private $partamtwo=false;
private methodoneflag=false;
private methodtwoflag=false;

public function __construct(){
}

private methodone(){
$this->methodoneflag=true;
..... выполняем метод
$this->param=результат;
}

private methodtwo(){
$this->methodtwoflag=true;
..... выполняем метод
$this->paramtwo=результат;
}

public method __GET ($var){
Тут проверяем через $$ имя входной переменной и если это param, то проверяем $this->methodoneflag и если он тру, то просто делаем return $this->param, а елси нет, то запускаем этот метод.......
то же и с остальными параметрами....
}

}

мне кажется это удобным (в случае, елси надо получать какие-то данные).... т.е. просто в клиентском коде запрашиваю myclass->$param и все.... класс сам заботиться какой метод запустить и надо ли вообще это делать.... т.к. может чуть раньше мы запрашивали другой параметр из этого метода и смысла выполнять его дважды нет, а просто вернется нужное значение...... И вообще, эти параметры можно передавать по ссылке, что вообще облегчит жизнь.....

Меня смущает лишь то, что у аксессора появляестся много if или Switch...... НАсколько такой подход имеет право на жизнь? С какими трудностями я столкнусь при нем?

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

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

Да просто пока не очень получается ОБЪЕКТНО ОРИЕНТИРОВАТЬСЯ... т.е. именно мыслить объектно...... и все пока сводиться к удобному размещению функций((((..... а мышление, увы, пока процедурное...... НА данном этапе это просто класс, который беред данные из БД, ну и проводит соответствующую обработку/вычисления.... и на выходе уже данные, которые можно передавать на отображение...... Просто метод возвращает много значений и загонять их в большой массив и делать return не очень хотелось.... посему придумал, чтобы метод просто присваивал бы членам класса нужные значения, а доступ к ним в клиентском коде, можно было бы получать по-отдельности.......

>Вы полиморфизм себе так отключаете, так как не может уже обязать класс иметь методы с определенными именами. В ООП PHP и так довольно мало инструментов, а вы еще один исключаете.
>
вот тут, если можно, поподробнее..... Стыдно признаться, но понятие полиформизм я так и не понял(((..... а обязать этот класс реализовывать методы - можно же интерфейсом или нет?

Специально добавлять "объектно-ориентированности" не нужно - только хуже сделаете.

>Просто метод возвращает много значений и загонять их в большой массив и делать return не
>очень хотелось....
Вы смотрите не то, что вам хочется, а то, что хочется внешнему разработчику. Ему думаете будет удобнее по сту раз ваш объект дергать, пока он все данные не выдоит? Разработчику хочется быстрее решить задачу, т.е. послать запрос и получить ответ с меньшим количеством операций и набора данных. Поэтому если конструктор съест запрос, а один метод выдаст результат, внешний разработчик будет крайне доволен. Вы лучше в своем объекте обработайте ошибки выполнения запроса и сгенерируйте исключения, чтобы их можно было поймать при блоков помощи try ... catch ... внутри которого будет штук 20 запросов и нужно точно выяснить не только что за ошибка, но и где она произошла. В ООП хватает работы без намеренного усложнения интерфейса.

>вот тут, если можно, поподробнее..... Стыдно признаться, но понятие полиформизм я так и не
>понял(((..... а обязать этот класс реализовывать методы - можно же интерфейсом или нет?
А вот представьте, что через два проекта у вас появилась задача работать с двумя базами данных одновременно, вы наследует от этого класса еще один, а еще через два проекта у вас появляется необходимость работать с другой СУБД, потом с третьей, потом с четвертой, а потом с четырьмя СУБД одновременно... и важно чтобы имена методов у всех объектов были одинаковые, так как вы их в цикле обрабатываете. Полиморфизм - это когда у вас не только метод sql() везде так называется (а не query() и не do()), но и вы знаете, что наследник его обязательно реализует, так как в противном случае выполнение программы завершиться ошибкой. Если все работает, у него этот метод есть и называется он sql(), причем не важно сколько классов в дереве наследования - они все обладают этим методом. Интерфейсы классов выглядят одинаково, а внутри у них все реализовано по-разному. В противном случае появляются блоки switch - это первый признак, что полиморфизм перестал работать и он у вас уже есть - чего-то не то делаете, если switch пошли.

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

Отлично отлчино, как раз в Вашей книге "ООП на РHP" написано про if-блоки.... Кстати очень хороший пример про иерархию транспорта....
Вот только сейчас реально столкнулся с вопросом одинаковых имен методов у базового и производных классов...... И вот тут возник еще один вопрос..... Наверняка на него есть однозначный ответ.
Предположим мне нужны несколько singletone-ов, причем базовых..... хоть базовых классов будет и немного, но даже если их будет 3-5 шт. в каждом прописывать метод instance, причем абсолютно одинаковый кажетсья глупым..... С другой стороны создавать один singletone и от него наследовать все singleton-ы приложения - тоже мне кажетсья не очень.... Где-то также вычитал , что глобальные источники (переменные, методы) - это зло, т.к. класс привязывается к какой-то части приложения вне интерфейса и не может быть просто выдернут и поставлен в другое приложение...........Как поступают в таком случае?

Очень абстрактно, не знаю что посоветовать, расскажите подробнее об этих синглетонах, что они будут делать и зачем они вам?

Ну пока это еще на стадии теоретической разработки, но например...... вот контроллеры страниц.... т.е. для каждого типа страницы (страница каталога, страница корзины, страница описания товара и т.п.) будет свой класс контроллера. Наверно правильнее делать их синглтонами, чтобы случайно не наделать кучу экземпляров.... Ну и такие методы как run сделать абстрактными в абстрактном классе и все контроллеры наследовать от него.... ну вот для каждого контроллера писать одинаковый instance не хочется........ Инстанс стандартный


public static function getinstance(){
if(!self::$instance){
self::$instance=new self();
}
return self::$instance;
}

Кстати есть еще вопрос по поводу того, как должен выгляджеть контроллер, но я его задам в другой ветке.....

Давайте начнем с начала. Мы в свое время когда писали книгу "PHP. Объектно-ориентированное программирование" именно поэтому не стали касаться шаблонов, для PHP их по большому счету нет, а из других языков они смысла не имеют. Давайте, посмотрим, что же такое паттерн с красивым и загадочным названием синглетон. Это класс, который гарантирует, что объект будет один, сколько бы потребителей его не запрашивало. Очень удобно, когда есть большой объект, занимающий много памяти и не очень ясно время, когда его лучше создать, а что самое главное нельзя допустить чтобы такие объекты сотнями плодились - ведь достаточно одного. Это очень важно в таких языках, как C++, где вы самостоятельно управляете памятью, создадите 100 объектов, под 100 объектов память и будет выделена, создадите только 1 объект - память будет выделена только под один объект.

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

Теперь давайте посмотрим что происходит в реальности. ПО разрабатывают не дураки, PHP (точнее расширение для работы с базой данных) так и так не дает создавать несколько соединений для одних и тех же данных, просто возвращая при повторной попытке соединения уже созданный ранее дескриптор. Синглетон важен в длительно выполняющихся программах, когда программа работает долго - несколько часов или даже месяцев. Нельзя в таких условиях держать память зарезервированной - месяцы простоя памяти слишком дорого. PHP-скрипт мало того выполняется максимум 30 секунд, так еще на каждого клиента создается свой собственный экземпляр со своими объектами и синглетонами. Хорошенький синглетон получается: сколько клиентов, столько и синглетонов... а есть ли в нем смысл тогда, если границы его действия один PHP-файл (ну пусть с включениями)? Память не экономится, код усложняется...

Да в C++ вы под любую переменную, кроме базовых типов выделяете память, однако в PHP за вас это делает интерпретатор. Вам не обязательно создавать объект класса, вы можете его объявить статическим - вот вам и готовый синглетон (если в нем вообще есть смысл), статический класс со статическими методами ведет себя ровно так же как магический синглетон - занимает ровно одну позицию в памяти и вообще не имеет объектов, только методы. Так может контроллер и сделать статическим, раз вам от него только методы нужны и чтобы он в единственном экземпляре существовал?

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

Вот вам реальный пример. Допустим хранятся параметры сайта в таблице базы данных, при первом обращении вы извлекаете их и кладете в массив $_SESSION, далее уже берете их от туда, не дергая таблицу. При этом у вас в коде сотни обращений к параметрам сайта - где в первый раз вам они потребуются, вы не знаете, в каком месте нужно производить инициализацию в $_SESSION не ведаете. Вот самая задача для синглетона (только называть его следует по-другому), который может быть реализован как объект, может быть реализован как статический класс, может быть реализован вообще без ООП, просто в виде функции, которая принимает имя параметра и возвращает его значение. В синглетоне это может быть удобным в силу того, что вы можете обратиться к параметру $parameter->numberpage, для присвоения, для чтения, а класс выполнит всю подковерную работу, да еще может проверит, нет ли у текущего пользователя личного кабинета и не выставлял ли он в нем какие-то свои настройки, отличные от общесайтовых. Вот это ООП и польза от него, а контроллеры ради контроллеров - это намеренное усложнение кода, по крайней мере сейчас, когда вы не совсем понимаете что делаете, и вообще не представляете какая вам с этого польза. А пользу нужно всегда представлять - иначе смысла задействовать ООП нет, без пользы, это просто более длинный и запутанный способ написания кода.

PS Паттерны для PHP нужно разрабатывать свои собственные, все, что другие паттерны решают в других языках, тут решено уже до ООП. Это не значит что все паттерны не имеют смысла, это значит, что нужно учитывать, что это чужие паттерны из других языков и смотреть - выгоден вам тут этот паттерн или не очень.

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


Вот тут меня немного в другую сторону клинить начинает... До недавнего времени я все параметры передавал из класса в класс. Т.е. все было дико последовательно и независимо... Класс модели вообще не знает что такое сессия, он просто получал параметр на вход. $_Session, $_post, $_Get - этим у меня занимается отдельный класс, который получает, фильтрует и т.п. Но потом я подумал, что можно же, например входные параметры от пользователя, после обработки записывать в некий класс реестра. И из любой точки кода к этим входным параметрам есть доступ (только на чтение конечно). Но вот прочитал в одной книжке, что глобальные штуки - это зло..... т.е. и правда, уже ничего без реестра работать не может, появляется связанность... Посидев, подумав, я пришел еще к более адскому открытию... Ведь соединение с БД дико глобально... Не передавать же дескриптор соединения каждый раз в конструктор классов? Да и много таких нужных штук.... напмреир хочу реализовать класс datatime handler, который напрмеир будет содержать метод int-to time, чтобы дата, которыя в БД храниться как INT - преобразовывалась в человеческий формат...

Или это уже загон? Или может есть граница, где глобальные переменные и методы допустимы, а где это реально зло?

Объекты $_SESSION, $_POST, $_GET - это объекты среды, вы не сами их вводите, поэтому оперировать ими все-равно придется. Это неизбежное зло. Названия индексов в самом деле слишком глобальны - это бы хорошо было инкапсулировать внутри класса-реестра. Однако, один класс на весь сайт - это слишком много (это все-равно, что класса нет), лучше их локализовать по задачам и группам объектов. Т.е. формы обслуживает один класс, настройки сессии - другой, URL страниц сайта - третий, может что-то свое придумаете. Создание иерархии классов - это создания собственного языка, дело не простое, но если язык создадите удачный - он вам сэкономит массу усилий и времени.