Привет

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

Особенно красиво Получается агрегация: есть Объект одного класса содержащий кучу ссылок на объекты другого класса. 
Когда программа "перманентно" находится в оперативной памяти (как приложения GUI на десктопе), один раз срабатывают конструкторы, а дальше уже с существующими объектами работаешь. Можно их перемещать из "контейнера" в "контенер", манипулировать "контенерами" и так далее. 
Все в памяти, все под рукой. + Удобная понятная структура.

Но вот в PHP скрипт у нас срабатывает по запросу пользователя. При каждом переходе по ссылке нет возможности перенести ООП структуру, ее надо формировать с 0, вызывая все конструкторы давая запросы базе данных и так далее. В Сессии ее не всегда перенести удастся. Выглядит слишком дорого, и черезменро усложнено.

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

Тогда же как в программах постоянно висящих в памяти, как я уже говорил удобно и красиво обращаться системами На ООП .


Что собственно нужно:

Нужны книги, статьи или советы про то как проектировать ООП приложения под PHP.

Вот такая вот дилемма у меня возникла во время попытка написать красивую ООП программу. С одной стороны хочется использовать ООП потому что красиво и удобно, с другой стороны не совсем понятно как это реализовывать с такой "дискретной" спецификой.

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

Сей час думаю как эту задачу поделить на классы и объекты для реализации.




 

Это сообщение отредактировал(а) Dima50 - 25.8.2009, 13:12

php заточен для использование в web, протокол (http) и специфика взаимодействия клиента и сервера не заточены под такое использование классов, о котором вы говорите (десктопно).
А вопроса по существу я не увидел, кроме задачи. Но ее конечно же никто не будет решать за вас

С таким подходом и правда лучше не использовать ООП... И почему же работать с полями класса хуже чем с массивом? Основное внимание нужно обращать не на то, сколько вызывается конструктор, а на то какой объем информации будет передан классу и как он с ней будет работать. 



А с отказом от ООП удастся избавится от запросов к базе?

откуда такие данные? В чем экономия?

Есть класс пользователь. Надо вывести пользователей зарегестрированых в системе. 

Быстрей сделать запрос к бд, вывести имена пользователей. Чем на основе запроса БД формировать обьекты для каждого пользователя. А потом проходить по созданым обьектам и вызывать метод печати имени (или ссылки) для каждого обьекта.

  

а вы не делайте так. сформируйте объект, сделайте запрос и выдайте список

Объект какого класса? 

Ты имеешь ввиду сформировать один объект Пользователь. Получить набор строк из БД где и каждую строку подставлять в этот обьект.
Вместо того чтоб использовать множестов обьектов класса Пользователь.

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


Сей час в чем хочется доскональна разобраться:

• В том как разделять задачу на классы без избыточности для ПХП. 
• И использовать полную мощь ООП ПХП.

Кстати использую для работы Code Ignitor.
 


Это сообщение отредактировал(а) Dima50 - 25.8.2009, 14:01

тогда не используй

Поясни

Это сообщение отредактировал(а) Dima50 - 25.8.2009, 14:58

нет, я говорю: сделай один объект подключения к БД, один метод для запрос выборки и вызови один метод построения списка пользователей

но CI как раз ориентирована на РНР4-5 (больше на 4рку) и всех прелестей ООП не предусматривает (с 5той версии ООП в рнр начинает нормально развиваться) 

Dima50, мне кажется, вам для ваших целей ORM нужна. Это несколько более отдаленная (продвинутая/сложная) тема от среднестатистического веб-строительства.

Понятно. 

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

Нужны качественные источники по проектированию систем именно для PHP, в которых на примерах излагается где нужно и своевременно использовать наследование, refleciton, интерфейсы.

Добавлено через 12 минут и 42 секунды


Да, CodeIgniter совместим с php4. Но разве это мешает в собственных классах использовать возможности php5?

Спасибо за толковый совет. В этом направление не смотрел даже.