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

Devider, Снова вы на конкретные реализации привязываетесь... Вам ли не все равно, как будут кешироваться конфиги: пофайлово, поштучно или вообще генериться в нативный php-код? )

Учитесь абстрагироваться от кода - это для меня важнейшее качество ООП-подхода. Почитайте банду четырех - вообще летать будете, когда начнете применять паттерны ;)

Все равно. Хранить в базе, кешировать в файлы. Главное - где это возможно отделить код от данных.

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

Банду четырех обязательно почитаю, спасибо за наводку )

asserte, тут одни уже доабстрагировались.

Жил был себе такой проект gallery2 и являлся лучшим в своей нише по набору фич. Недавно он объявил о закрытии старой ветки и переписывании с нуля : http://gallery.menalto.com/gallery_3_begins

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

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

Насчет расширений... А вот тут уже вопрос не ООПрограммирования и не ООПроектирования. Тут архитектурное проектирование задействовано.

Я что-то очень сомневаюсь, что они на процедурном напишут =)

А по теме "доабстрагировались" - не означает, что на каждую сущность системы надо по 20 оберток писать. Я к адаптерной системе в 2 обертки пришел. Ничего - шустренько работают системы (профайлинг показывает, что основные 90% - это СУБД). Не стоит говорить о ООП как о сильно тормозящем системы подходе. Системы можно тормозить еще и циклами :)

циклы надо в натив си функции сворачивать)) (array_*)

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

Мозг core-разработчиков полностью съеден ООП и ORM, отсюда и "неправильная" структура таблиц, которая с их точки зрения очень даже правильная. Там даже кеширование есть, только это не спасает.

Довольно удачно в этом смысле построен vbulletin :

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

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

Впрочем, холливар =)

мои 5 копеек.

к сожалению тему читал по диагонали, так что если повторюсь, извините.

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

Пример: есть $_GLOBALS['config']['param']. И у этого параметра есть какое-то значение.

Второй разработчик, считая, что эта переменная больше не понадобится, с чистой совестью делает unset. А вы, ничего не подозревая, используете ее. И в данный момент времени все прекрасно отрабатывает (вместо переменной передается null, что пускай является корректным параметром). А в другой момент времени вывалится ошибка, но проект уже запущен.

Что позволяет сделать класс (не ооп)? Ответ: определить поведение! Можно установить для конфига readOnly свойство, можно сказать классу выбрасывать исключение (Exception) при доступе к неопределенному значению, можно сериализовывать и обратно (вроде, было уже сказано выше).

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

Про ооп я пока промолчу.

А про ООП можно добавить просто, что помимо знания о поведении объекта мы сможем тиражировать это самое поведение (наследовать, дополнять, расширять и т.д.), не переписывая каждый раз все заново (D.R.Y., если не ошибаюсь :)).

а давайте представим реальную ситуацию - ооп в пхп. зачемтут тиражирование обхектов? новости, статьи и тп, они же все будут все равно ПО РАЗНОМУ добавляться, так что тут имхо плюсов меньше чем минусов. что можно реально НАСЛЕДОВАТЬ, ФАБРИКОВАТЬ в сайтостроении? в голову приходят только вещи вида адаптер для доступа к бд, больше с лету ничего припомнить не могу ... конечно все зависит от архитектуры вебприложения/сайта, ООП повышает хакоустойчивость сайтов имхо.