Зачем нужны классы в php?

Примеры? Пожалуй, TreeStructure - как пример. Добавление/удаление Items/Nodes (одинаковые методы - только вот разные таблицы, которые можно переопределить при наследовании). Сюда попадают все нециклические деревья: категории/статьи, категории/картинки, категории/видео и т.д... Вот вам и наследование... =)

вы шутите? я соглашусь что дерево может храниться в разных таблицах. НО! это надо передавать в конструкторе к классу обертке TreeStructure и не больше, нахера тут наследование?))))))))))))) Наследовать в картинках/видео/аудио... всего лишь extends TreeStructure в котором $treemanager = new base("video_catalog","video_files"); или тп?

ps:// может конечно я не понял предлагаемую архитектуру

К вопросу о наследовании. Честно говоря не понимаю, что тут можно не понять? Это обычная древовидная классификация. Макулатура делится на книги и тетради, книги делятся на детективы и философию, философия делится на немецкую классическую и современную и т.п.

Простой пример.

У тебя есть магазин. В нем продаются предметы с общими свойствами - цена, титл, описание и т.п.

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

непонимаю.

а если я захочу добавить поле в мукулатуру(книги) к пример? мне надо будет править исходник? "да ну вас на *** с вашим ООП отвечу я тогда вам".

вам достаточно исправить/добавить ТОЛЬКО нужное свойство и/или нужный метод в новом классе, все остальные наследуются

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

ОФФ: bearman, кала на форуме хватает, такое ощущение, что копрофилы сплошные

я и так на нем, только ножки свесил

не понял назвали в ыменя калом или нет ..... ну да ладно. получите плюс)

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

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

Все, что угодно.

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

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

$article->title = 'Заголовок';
$article->content = '<h1>Статья о преимуществах ООП</h1>';
$article->save();