Форум PHP

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

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


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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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