Форум PHP

Вот задался такой мыслью, чем же все-таки ООП лучше структурного программирования? Ведь повторного использования кода можно добиться и с помощью функций... Да и скорость выполнения скрипта существенно замедляется. Вот скажите, почему же Вы делаете упор именно на ООП, все Ваши книги повернули в его сторону. Я вот привык к структурному программированию, и совсем не ощущаю потребности в чем-то, мене всего хватает. Откровенно говоря, не могу понять всей сути ООП, читал вашу книгу про ООП, все равно не понимаю к чему это все? Ради удобства? Вы говорите, что ООП нужно использовать только в действительно необходимых случаях, а я вот даже не нахожу этих случаев.

PS: Оч хотел купить вашу новую книгу Практика создания веб сайтов, только в Киеве нигде не нашел. (

ТОже так думал, совсем недавно... Но потом понял:
Предположим у нас есть переменная хранящая в себе все данные о пользователе. Если использовать функции для работы с этими данными, то в каждой функции надо будте прописывать эту функцию (то есть писать function user_edit_name($user_array) {...} ), а в ООП этого не надо, только в какой нить функции указать и всё... Я конечно приёл не самый удачный пример, просто сейас пока в голове ничгео более умного нету :)

ООП имеет смысл использовать при разработке больших проектов.На форуме уже были подобный темы,воспользуйтесь поиском

>Вы говорите, что ООП нужно использовать только в действительно необходимых случаях, а я
>вот даже не нахожу этих случаев.
Таких случаев в ООП действительно не очень много - все окружающие интерфейсы процедурные. Мы попытались продемонстрировать одну из таких задач на примере конструктора HTML-формы с автоматической обработкой вводимой информации, и наследованием элементов управления, когда однажды разработанный код не дублируется далее.

PS По сути ООП эффективен только в таких иерархических задачах - процедурным программированием тут тоже можно добиться изрядного повторного использования кода, однако, это сложнее, по сравнению с ООП.
PPS А так ваши ощущения верны, зачастую ООП не всегда оправдано применяется. ООП и процедурное программирование не противостоят, а дополняют друг друга (по крайней мере в PHP) - не следует отказываться от полностью от того или иного инструмента. Объектно-ориентированный подход эффективно работает в больших проектах и системах, PHP, как правило, применяется в более скромных проектах, поэтому не всегда очевидно как зачем в языке нужен объектно-ориентированный подход.

Спасибо, будем знать. Но в каком смысле больших проектов? Т.е. тех, которые имеют большое количество кода? А чем тогда структурное программирование хуже?

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

Да я с вами соглашусь зачем ООП ведь структурное ничем не уступает да и по скорости выполнения структурное немного быстрее ведь в ООП класс это объект который создается динамически т.е все лежит в памяти (оперативной). Но просто нет таких таких уж через чур больших проектов в web ПРОГРАММИРОВАНИИ ЧТОБЫ ОЩУТИТЬ ЧТО ТАКОЕ ООП.
Вот на мой взгляд вы сравниваете трактор К 700 с трактором Белорус
и примерно говорите следующее гружу блин пол телеги (2 тонны) груза на К 700 и везу блин и тоже самое на тракторе Белорус какая разница !!!
Я вам скажу разница в том что у них немного разное предназначение!
Если вы знаете что такое механизм наследования думаю вы не зададите больше такой вопрос!! Вот возьмите завтра и напишите ОС не Windows а какой нибудь RassiaWindows и я посмотрю на ваше структурное программирование !!
Просто когда мы в книжках видим пример ООП и тот же маленький пример или отрезок кода структурного программирования мы говорим что структурное лучше просто чтобы описать преимущества ООП книги не хватит вы ведь представляете какие примеры будут и наврят ли кто вообще их разбирать захочет !!
Всегда прежде чем анализировать задавайтесь себе вопросом а коакое у кого предназначение чтобы не задавать вопросов что лучше !

> Вот возьмите завтра и напишите ОС не Windows а какой нибудь RassiaWindows и я >посмотрю на ваше структурное программирование !!

А вот товарищь Торвальдс взял и написал :) И без ООП совсем.

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

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

Да собственно ядро Windows тоже без ООП писалось, вернее без ООП-поддержки (без классов, наследования и т.п.), процедурный код просто оформлялся в парадигме ООП. Это кстати классический пример создания объектно-ориентированных приложений на языках без поддержки ООП. С другой стороны можно привести массу примеров ООП-приложений, где ООП только мешает разработчикам и запутывает, где без него они бы справились быстрее и элегантнее. Вводить объектно-ориентированные элементы в приложения можно только после того, как дан ответ на вопрос: зачем это делается, какая выгода будет получена и как её измерить? Ответы: это круто, там же можно использовать наследование, с ООП можно быстрее разработать приложение, все уже давно на ООП перешли, следует рассматривать как "Использование объектно-ориентированного подхода не целесообразно".

Спасибо всем за столь познавательные ответы!
Для себя я понял, что ООП я буду использовать только в тех случаях, где без него сложно обойтись, в той задаче, которая действиельно будет требовать вмешательства ООП, но пока я с такой задачей не встретился, но как говорится "Все впереди"!
Спасибо.