I
3. Всюду объекты
II
Понять принципы ООП по плечам не каждому. На это нужно годы труда, куча практики и т.д. Вы пробовали написать модульный тест на процедурный код? Могу сказать, что задачка не из легких, особенно если объемы кода достаточно велики. А как насчет расширяемости и повторного использования кода? И вовсе не той, когда для расширения поведения вы перекрываете родительский классы.
Проблемы ООП разработчиков, ИМХО, из книг, на основе которых они изучали ООП. Авторы их перешли из ПОП области в ООП и многие проблемы принесли с собой.
ООП, имхо, куда больше мода, чем потребность. Люди начинают учиться согласно моде, а потом уже от привычки им это кажется удобнее. Реально же ООП в веб-программировании удобно в очень редких случаях.
Вот именно. То есть люди изучают просто синтаксис и не понимают, в чем суть наследования, что такое инкапсуляция, что такое роль объекта и зачем нужны интерфейсы и т.д.
Последние тенденции в развитии ООП, а именно гибкие способы разработки (Agile Methods), привели к изменению отношения к наследованию и перегрузке. Классы становятся меньше, более специализированными, увеличивается роль делегирования. Без знаний шаблонов проектирования и модульного тестирования писать качественный ООП код, который был бы удобнее, чем ПОП код - нельзя.
Возможно, что это все очень субъективное мнение. Я начал программировать сразу с объектного кода и практически никогда не занимался ПОП. Причем все это началось с книг GoF, Буча, Р.Мартина, XP и т.д.
Насчет PHP4 - не могу сказать, что реализация ООП здесь совсем кривая. Сейчас мы работаем над проектом, который на 98% состоит из объектного кода. Особых проблем пока нет, раздражает только отсутствие минимальной типизации и интерфейсов. Это приводит к тому, что код нужно тестировать более качественно и подробно - увеличивает объем работы. Все остальное - множественное наследование, перегрузка, конструкторы, деструкторы - по большому счету лишние. Даже без исключительных ситуаций можно обойтись.
