Форум PHP

Который объединен в одну логическую структуру. Например, классами исключений, обработкой ошибок, и т.д.

Набор классов.

А что такое FrameWork?

FrameWork я уже разрабатываю. Там есть классы для работы с файлами, csv, базой данных, даже шаблонизатор сделал. Пусть будет на уровне фреймворка, т.к. это просто классы. Осталось только универсальный парсер xml файлов сделать - классы для чтения/записи xml файлов.
Правда, это только классы, которые принимают/возвращают массивы. объеденены они только классами исключений. К.л. еще более организованной структуры нет.

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

Когда доделаю, может быть выложу это все в паблик, если доделаю.

P.S. Кстати, чтобы что-то разработать более полезное, надо бы узнать как разрабатывать это полезное.

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

Спасибо, понял.
Кстати, про гостевую книгу, если вы про мой тот пример, то это только пример.

>Во-вторых, не вижу проблем с жизненным циклом объектов. Если таковые есть, то я про них не знаю.
Создание объектов требует дополнительной памяти и затрат процессора, если в C++ или Java объект один раз за всё время работы программы создался и один раз разрушился - это на общем фоне не заметно, а вот когда к вам приходит пару тыщ человек и для каждого создай и разрушь объект, да ещё средствами интерпретатора - производительность падает и сильно (этот факт отмечаемый многими - только Страуструпу (создателю C++) удалось свести накладные расходы по созданию объектов к нулю).

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

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

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

Я знаю, что класс в первую очередь это атд. Вот потому (что атд) я и пишу, что удобнее. Полиморфизм же позволит не заморачиваться с наименованием методов. Разве можно такое сделать с помощью обычных функций?
Вот небольшой пример на моем блоге - http://www.phpforum.ru/index.php?automodule=blog&blogid=13&showentry=38