ООП - зло. Ваше мнение.

Любая абстракция и благо и зло одновременно. Все зависит от рук. Если интерпретируемые языки доросли до ООП парадигмы, из этого можно сделать три вывода:
1. Отношение мощности железа к его стоимости существенно возрасло.
2. Программы стали настолько сложными и большими, что время их разработки стало дороже, чем экономия ресурсов железа.
3. Это уже работает в условиях рынка. А рынок - сам себе регулятор.

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

ООП шикарно.
Ибо без классов написать чегонить нормальное не на пхп невозможно.

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

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

но если вы создадите проэкт который надо будет модифицировать то во всем бесконечном количество кода с неявными тот кто будет доделывать повесится! да вы и сам через пол года будете думать что это за хрень вы написали и как оно работает!

Кстати я смотрю вы и в жизни не делаете все как надо:
в пейнбол играть же опасно можете нанести себе повреждения. .
а едите же вы не то что полезно, а то что вкусно!

Всегда приходится выбирать между двумя крайностями. Когда пишешь простенький калькулятор, который не будет со временем модернезироваться, то ООП зло. Но когда пишется более менее крупное решение, то простота написания, поддержка, расширяемость выходят на первое место. И здесь структурный код может создать определённые трудности. При этом ООП не стоит на месте и постоянно оптимизируется. Здесь говорили о Java.Как пример приведу технологию EE.Основным действующим объектом там является Bean.Он "тяжёлый",многое умеет. Если бы его функциональность пришлось писать руками, то разработчики бы вешались. В итоге его обернули разными обёртками, интерфейсами. Теперь его вызов заключается всего в одной строке:
@EJB MyBeanRemote mb;
Разработчики вздохнули. А всю оптимизацию возложили на контейнер бинов. Теперь заранее создаётся пул бинов. В нужный момент из пула по требованию контейнер берёт готовый бин и вызывает на исполнение его метод. По окончании бин возвращается в пул. Теперь при каждом вызове не тратится время на создание и уничтожении бинов. И это работает очень быстро. Хотя и ООП. Так что и в PHP,я думаю, ООП писалось не от балды бестолковыми студентами. Всё насколько можно оптимизируется и постоянно усовершенствуется. Частично ответственность на оптимизацию возлагают на разработчиков серверов.

При современных мощностях я думаю то не так критично. Java - это интерпритируемый язык? И он полностью ОО. Однако он по производительности мало уступает компилируемым. Я думаю, что ООП довольно полезная штука.

UPD: java плохой пример, но все равно от ООП уйти можно только к более сложным и громоздким кодам и алгоритмам, которые еще больше замедлят работу программы, имхо.

Нужно же чем то жертвовать ради удобства
Даже существование яву сама по себе жертва взамен возни с асемблером
Получается так

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