Привет

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

Особенно красиво Получается агрегация: есть Объект одного класса содержащий кучу ссылок на объекты другого класса. 
Когда программа "перманентно" находится в оперативной памяти (как приложения 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?

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

Речь идет о полной поддержке PHP5. В частности, я бы посоветовал начинать уже с всех преимуществ PHP 5.3 и использовать Zend Studio 7.1 или на крайний случай netBeans.

Добавлено @ 19:54

Только нужно учесть, что данный подход больше подходит для безнес-решений. Т.е. для highload систем он может стать действительно узким местом.

 Ой, ну что за чушь   

Это специфика PHP, все остальные веб-ориентированные языки это умеют: в них запрос обслуживает не копия приложения, а лишь отдельный поток единожды(или неск. раз) запущенного.

На сколько я знаю Zend Studio и netBeans - среды разработки (aplication development environment), а CodeIgniter - MVC framework при том достаточно легковесный.  
Чем среды разработки помогут в использовании полной мощи PHP?

Сказать честно я уже с неделю подумываю прейти на что-то IDE вроде Aptana, Zend Studio, NetBeans. Сей час пользуюсь VIM c него не ухожу потому что потратил год на работу с этим редактором.

Чем-то чую что работа с VIM смахивает в  на войну америкосов во вьетнаме. Времени потрачено уйма, по сему оступать не хочется. Но с другими системами было-бы быстрей.

Думаю что лучше весего переходить на Zend. Он случайно бесплатным не стал? 1.5 года назад он был триал 30 дневный.




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

А бизнес решение это проект средней нагрузки или система учета "бизнес-процессов" (учет времени, планирование).

 Примерно тем же, чем может помочь автомобиль при переезде из Владивостока в Мурманск: с одной стороны можно и пешком, но... долго, ненадежно и неудобно.


 PDT - его бесплатная реализация.

Прошу меня простить, я было подумал что речь идет об устаревшем редакторе. В качестве фреймворков могу посоветовать Zend и Symfony.


Дело в том, что в Zend сильно заточен на Zend Framework имеет множество полезных плагинов и расширений. Взять хотя бы модули контроля версий SVN/CVS.


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



Именно. В первом случае, порой, приходится использовать нестандартные решения. От named и до патча для реализации транзакций в mecached.
В последнем случае - главное логика, скорость и удобство разработчика и пользователя.

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

Ипатьев, с ORM не работал. Но использовать подход, создавать объекты на каждый тюк - никто ведь не мешает? 

P.S. Я видел подобный подход на одном из наших проектов, но по сути, реализация его была убога.

Так автор же в первом посте описал - чем мешает.
По сути его вопроса ответов, по сути, и не было. Были только шаблонные рекомендации-заклинания - ORM, объект для работы с базой...
Меня данный вопрос тоже интересует. От ООП в пхп очень часто встречается лишь внешний вид, синтаксис. Причем большая часть техник, как совершенно справедливо автор пишет, оказывается лишней, ненужной. 
Критиков много, но за кучей слов о рефакторинге, управлении кодом и прочим теряется само понятие объекта, того самого яблока из учебника.

а его и нет, жизненный цикл у веб приложений по другому строится, не как у десктоп приложений.
Но кто сказал, что должно быть так же? Что, на asp по-другому?
А взять клиента с его js, в прототипном программировании по-другому только из-за того, что приложение дольше живет,
есть механизм событий и т.д. В php этого изначально не может быть по его природе. 
Кстати в десктоп приложении я не буду строить список объектов для всех записей, а потом вызывать метод вывода для каждого. К примеру у меня 1000 пользователей. Что, мне создавать 1000объектов для каждого? Проблемы с проектированием, но не у меня в данном случае.
 
Согласен, для любого приложения

Похоже степень очевидности у нас различается.
ООП нужно применять там, где оно в совокупности производительности и удобства (где на первом месте все-таки производитьельность) будет выигрывать. А если бытовое понимание применять везде, где вздумается...

Следовало, наверное, уточнить, что производительность имеется в виду разработки, а не кода ;)
И вот именно поэтому я в предыдущей дискуссии на эту же самую тему заметил, что вопрос "зачем ООП в РНР" стоит формулировать как  "зачем ООП программисту"...
А ответы сводятся к тому, что ООП упрощает клепание типовых сайтов на конвейере. Грустно.

очень грустно

Задача публикации этой темы определить наиболее подходящий стиль проектирования и разделения задачи на классы и объекты для web проектов.

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


Инструменты в языке есть и от версии к версии они совершенствуются, нужно разобраться как и где их использовать.











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

ООП ради ООП встречается не только в РНР, но и в других языках. А вот про недоступные в РНР техники проясните, плиз.


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

Да, создавать, если вам нужно произвести с ними какие-то сложные действия. Например, начислить ЗП

1. Есть набор виджетов. Контент получают от удаленных сайтов. Страница собирается из конкретных виджетов, но, естественно, расчитывает на интерфейс BaseWidget. Ну и тут IZ@TOP недавно пример приводил по поводу фотолабораторий

В этой ветки примера про фотолабораторию не нашел.  

 Почему же?
PRADO PHP Framework
Delphi for PHP
ASP.NET в конце концов.

Те вещи, на которые вы ругаетесь, там достаточно прозрачны.


Только я бы не стал называть такую модель классической

Посмотрел я BaseWidjet по запросу в google, в основном находится для Java и JavaScript. Что-то для wordpress, но слыхивал я краем уха что ворпресс не особо ООП пользует. 

Я попробовал сам спроектировать базовый класс для PHP виджетов рассуждал так:

Виджет это:

С точки зрения клиента виджет это div - заполненный каким либо содержимым, при том содержимое у всех виджетов абсолютно различное от часов и последних сообщений в форуме. 
Общее оформление высота ширина обычно храниться в каскадной таблице стилей. 
Дополнительно к виждету нужен определенный скрипт на стороне клиента, без скриптов на стороне клиента не поработаешь.


Какие интерфейсы нужны в базовом класе:

•  Нужно что либо "визуализирующие" виджед, возвращающее хтмл строку.
•  Метод устанавливающий для виджета JS, CSS, Шаблон.
•  Интерфес для работы с базой данных (серилизации/десерелизации). Чтоб сохранять состояние виджетов.
•  Интерфес для ответов AJAX.
•  Конструктор/инструктор соответственно.

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

Вот ИХМО в первом приближение что надо вижедту.






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

http://www.books.ru/shop/books/693675

Купил, сейчас читаю, перевод местами хромает, а так - хорошая книга.

p.s. в сети есть pdf, правда на "французском".

Это сообщение отредактировал(а) xoma - 26.8.2009, 13:26

Ну да, мои исходники нагуглить нелегко. А эти, надеюсь, невозможно -- заказчик обидится. 


И? У вас получилось заметить полезность/бесполезность ООП?

Спасибо, вот по большому счету что и и скал.



конечно 

solenko, как раз потому что ООП удобно весь разговор и был начат.  

Такие части парадигмы как Наследование и Полиморфизм необходимы в крупных, а следовательно не тревиальных проектах. Человеку который каждый день вклеивает нарезаный шаблон в движок, пректирование не нужно в его работе. От сюда и высказывания типа ООП излишне.




Это сообщение отредактировал(а) Dima50 - 26.8.2009, 16:53