народ, прогаю лет около 10, начинал с бэйсков и паскалей... в общем, я очень консервативен и до сих пор принимаю только структурное программирование, хоть потихоньку начинаю применять и классы... собственно, как-то слепо... мне не совсем понятен их смысл... просьба привести конкретные примеры ситуаций, когда ООП имеет явные преимущества перед структурным программированием
благодарю 

навряд ли такое возможно. в смысле - примеры привести. 
по скорости разработки ООП вполе может превзойти процедурное, но только если:
- все участники процесса не понаслышке знакомы с ООП: если ты только вчера использовал функции и переменные переменных типов, то у других будут проблемы с твоим кодом(не соответствует идеологии: не переносимый и расширяемый), а у тебя - с пониманием чужого кода;
- задача действительно оправдывает применение ООП: к примеру, программы для контроллеров можно и на С++ писать, но если контроллер работает только с машинными кодами(пока что контроллеры, принимающие python-код редкость), то такой подход себя н оправдает.
по скорости работы и занимаемой памяти машинный код, полученный компиляцией ООП вполне может проиграть коду, полученному из процедурно-стилевого кода(таблицы виртуальных функций и т.п.), но несильно.
так что не совсем понятно, какого рода "преимущества" ожидаются.
да, если все участники знакомы с ООП, то преимущества вполне могут быть в:
а) скорости разработки
б) простоте отладки(пр правильном подходе имеем слабую межмодульную взаимосвязь и сильную внутримодульную - компоненты можно отлживать независимо)
в) простоте поддержки(модификация и коррекция)
г) расширяемость
д) повышенная повторная применимость

Почти все (а может даже и все) эти преимущества можно получить, используя пользовательские функции.    
А тем более, если быстродействие при этом повышенное. 

Или в чем я не прав?
 
Пытаясь читать про ООП, ничего не понимаю,   
может быть кто-либо из форумчан сможет лучше объяснить на примитивных примерах?   
 

    

а Вы попробуйте поработать с классами, это как пересесть на Мерседес с Жигулей, трудно потом отказаться.

Не прав в методике сравнения, с тривиальных позиций ООП рассматривать нельзя.

Именно в этом и вся загвоздка, применять ООП на примитивных примерах глупо и никаких преимуществ видно не будет. Смысл ООП поймёшь, когда начнёшь работать с проектами от 2-5 тыс. строк кода и более...
А когда встретишься с проектами, в которых и 10 kLOC не предел, тут уж и всю мощь АОП осознаешь...

Это сообщение отредактировал(а) source777 - 21.12.2008, 21:56

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


дайте не примитивный пример


ну скажем так, самый крупный мой php-проект весит более 3мб в исходниках, и я в нем вполне легко ориентируюсь, сколько там строк не знаю, т.к. более 600 файлов, не считал

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


skyboy, очень благодарен за Ваш пост, чувствуется, что писали по опыту, я в команде не работал и работать не собираюсь, это не по мне, привык все сам, так что данный пункт соответственно и упустил...

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


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

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


тут не обязательно дело в объеме кода. 
представим, что надо отрисовать на экране средставми openGL прямоугольник. 
стадия 1. создаем функцию. в неё пихаем 20 параметров: параметры отрисовыаемого прямоугольника(цвет, толщина линий, размеры), парамерты отрисовки(расположение прямоугольника на отрисовываемом пространства), параметры "полотна"(например, идентификатор окна в windows) и параметры инициализации openGL(около десятка). Вся работа - внутри единственной функции. Естетвенно, работать сложно. Изменять код - ещё сложнее. итак,
стадия 2. инициализацию openGL, подготовку контекста отрисовки и саму отрисовку выносим в разные фунцкии. в нашу "первоначальную функцию" все ещё передаются двадцать параметров, но внутри - только вызов трех других функций с передачей им соответствующих данных.
стадия 3. отделяем параметры друг от друга: группируем парамерты по смыслу, выделяя однотипные параметры(параметры иницциалзации openGL, параметры отрисовки, параметры отрисовываемого) в отдельные записи(в PHP для этой цели использовались бы ассоциативные массивы). теперь вместо кучи параметров в фунцкию передаются всего три. пусть, сложных, но управляться с ними будет проще. 
стадия 4. надо передать в функцию какую-то функцию. к примеру, чтоб при отрисовке каждой новой стороны использовать не один и тот же статически заданный цвет, а взывать определенную функцию, чтоб она уже генерировала цвет очередной стороны. и - стоп! у нас же ожидается в параметрах функции именно цвет, а не имя другой функции! Как же делать? Писать ещё одну функцию, которая ожидает в качестве параметра "цвет обводки" имя фунцкии, а не число? Или расширять имеющуюся функцию при помощи if'ов, чтоб шла проверка: если существует функция с таким именем, то вызывать фунцкию, нет - пытаться использовать как строку с заданием цвета? А если кадый параметр может стать динамически генерируемым? тогда как - писать под все возможные комбинации статически заданных и динамически генерируемых данных разные функции? или наплодить дерево if'ов, а затем повеситься с горя? 
итак, ООП:

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

но это ж сколько функций надо было бы создать! 

Плюс ко всему многие фреймворки используют ООП например Zend Framework.
И достаточно удобно структурировать код и разделять логики модель - вид - контроллер. 
А просто так этому не научишься. Мне понадобилось полтора года чтобы понять что к чему и то сейчас я допускаю ошибки в проектировке проектка.
Для страждущих к знаниям советую читать Гради Буча обьектно ориентированный анализ и проектирование потихоньку и помаленьку за 2 дня этому не научишься, а так же применительно к пхп есть книги PHP для профессионалов и ещё нашол такую книгу
http://www.softtime.ru/php5/?id_article=112
ничего сказать не могу потому что заказал ещё не пришла 
и такая 
http://www.ozon.ru/context/detail/id/3452954/ 
книга тоже есть
. 
http://taop.rpod.ru/rss.xml
вот ещё подкасты есть.

skyboy, вы наговорили кучу страшного и в итоге привели код, котрый и десятой части это всего не делает. В итоге вывод -- ООП позволяет делать меньше! Передергиваете, однако.