А вообще тем кто хочет понять ооп, и тем кто хочет прокачать свой скил в программировании, советую посмотреть в сторону фреймворка. Начать лучше всего с code-igniter изучить его, по ссылке очень хорошая документация, когда читал про него, мне все нравилось, но в последствии многие вещи, я посчитал лишними, и не нужными. После того как изучен кодеигнитер, самое время посмотреть что нибудь повеселее, kohana полностью ООП, HMVC паттерн, и еще много вкусностей. Сейчас сделаю один проект на ней, и пойду изучать yii

Совсем не обязательно все объекты должны умирать.
Объекты-«долгожители»  можно спокойно хранить в массиве $_SESSION
и тогда им уже ничего больше грозить не будет

Отсутствие событийности очень легко обходится при помощи javascript + ajax + php скрипт(ы), которые при разных запросах,
будут производить разные действия, 
например, применять методы к объектам, которые хранятся в $_SESSION

Впрочем, некая событийность есть даже при отсутствии javascript. 
Отправка формы или нажатие на get-ссылку: чем не событие?

такое впечатление, что ты, чтобы доказать что в php объекты не умирают, будешь всех их сериализовать/десериализовать в БД. Перечитай тему еще раз. java - это постоянно работающее приложение, которое отвечает на запросы, php - это набор скриптов, которые запускаются в результате запроса. Отсутствие событийности не надо обходить

На самом деле нету Объектное вс процедурное...
это скорее объектное + процедурное вс только объектное...

И здесь выигрывает однозначно объектное + процедурное...

Без самых базовых типов, куда мы денимся... все равно отдельные части всегда будут в процедурном стиле, как бы нам не хотелось...

да ладно. я первый год классами вообще не пользовался

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

> объектное vs процедурное

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

Тема древняя и бестолковая   Всё хорошо, и то и другое...

Лично я уже всегда использую объектное, процедурное только как "короткие формы" исключительно чтобы сократить код и для наглядности, например чтобы не писать это

достаточно сделать пару функций


Это сообщение отредактировал(а) Gold Dragon - 15.1.2013, 08:03

+1
Я не за "объектное vs процедурное", я за "объектное & процедурное".

Бред какой то. Тут большая часть вообще не понимает что такое ООП и с чем его едят.

Вот список вопросов для того, что бы оценить свои силы, в понимании ООП:

•  Как связаны abstract методы класса и protected?
•  Должен ли один public метод класса вызывать public метода этого же класса?
•  В каких случаях можно использовать static методы? Нужны ли они вообще?
•  Когда нужно использовать TypeHint и передавать объект, а когда нужно передавать сырые извлеченные данные из объекта в параметрах метода?

вопросы из контрольной?   Вот только интересно как по ним оценить знания 

большая часть вообще склонна к непониманию. я только один ценный пост вижу:

кстати, с чем положено есть гламур?

Это вопросы с которыми я столкнулся в процессе работы с людьми над большими проектами.
Если человек не знает ответов на эти вопросы, значит и код его будет доставлять неприятности всей остальной команде.
Вся процедурщина анархия вообще вытекает лишь тогда, когда человек не понимает для чего нужно ООП. В чём его предназначение.
Если же человек понимает, тогда "объектное vs процедурное" вообще не стоит, ибо первое создано что бы снизить сложность понимания исходного кода продукта.
Второй же подход не имеет инструментов что бы добиться снижения этой сложности, а потому в принципе не может больше подходить к разработке программных продуктов.


Это сообщение отредактировал(а) Deja_Vu - 1.4.2013, 14:27

Из школьной программы я ещё помню как устроена и принципы работы ядреной бомбы.. вот только не умею её делать   

Не совсем понял иронии.

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