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

Верно мыслите. Читайте теорию и сможете стать управляющим барака. ( архитектором-проекта).

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

В развитом и спроектированном языке эту проблему решили бы Пространства Имен, но в php их нет. (ну ладно, появились совсем недавно).

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

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

Все б новички такими понятливыми были:)

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

Например, так построен фреймворк extjs, вот пример описания класса: http://extjs.com/deploy/dev/docs/?class=Ext.tree.TreeEditor. У других классов есть такие же методы, но выполняют они другие функции.

U3RlcA==, суть Инкапсуляции вы почти поняли.

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

Полиморфизм - это когда кодер уже из третьей клетки не может и не хочет отличать ваши два класса.

Читайте теорию.

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

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

Devider добавил 01.02.2009 в 22:13

А не лучше свойства товара из базы брать, дабы пользователь мог из админки их задавать? Ничто не мешает создать глобальную переменную $SETTINGS, и подключать к ней наборы свойств. $SETTINGS['catalog'], $SETTINGS['products'], $SETTINGS['filter'] и т.д.

Или я чего то не понимаю?

ТС, бросай сразу процедурное программирование, и разбирайся с концепцией ООП, патом спасибо скажеш. В этой концепции можно добиться большей гибкости, нежели в обычном процедурном программировании. Если вы поймёте и овладеете концепцией ООП, вам в дальнейшем будет легче осваивать другие языки высокого уровня, вы патом просто не захочете даже использовать процедурное программирование. В РНР 5 концепции ООП отлично поддерживается. Класс - это описание свойств какого либа объекта, это если кратко. Разберитесь с этим поглубже, и всё станет со временем на свои места.

Devider

Никто не мешает то же самое и с классами сделать ;) Только без глобальных переменных (массив в качестве свойства класса или вообще использовать "волшебные" методы).

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

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

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

А для общих настроек существует паттерн Registry, дабы не хранить конфиги в глобальных массивах :D

ЗЫ. Но ведь можно сделать похитрее - в реестре хранятся общие (дефолтные) настройки, а в каждом классе можно прописать свои, более приоритетные ;)