Обьектно-Озабоченное Программирование.

Много лет я пытаюсь понять зачем оно нужно. Но не могу. За это время мною было прочитано множество литературы. Включая (но не ограничиваясь) таких авторов как Гради Буч (Иисус ООП :), Страуструп (а вот у него какие-то попсовые рекламные слоганы в смеси со старческим маразмом). А также сделано по этой методологии несколько проектов. Не помогло.

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

И я обращаюсь к присутствующим, способным аргументированно поспорить на эту тему. Сабж. Приведите конкретные примеры, иллюстрирующие преимущество ООП. Или программы, которые на ООП программируются проще и быстрее.

captain cobalt
Я делал OCX (http://www.vbrussian.com/download.asp?Type=Control&ID=88). Посмотри в хелпе раздел "Описание компонента", разверни все ветки. Смысл в том, что большинство элементов имеют заранее неопределенное число "потомков". А работа с ними должна происходить быстро и просто, например, в прикладной программе получен набор экспериментальных данных, их надо отобразить на графике. Просто подключаешь к программе OCX и пишешь:

With GraphEx.Layers.Item(1).Graphs.Add(. . .)
    .Math.Interpolate(. . .)
    .ShowNodes = True
    .NodesColor = &HFF&
    .AllowSelection = True
    .TrackSelection = True
End With

Все интуитивно просто и понятно. Попробуй на ассемблере сделать еще проще.
Если ты сможешь на asm сделать более удобную вещь, то, сэр, я склоняю перед вами голову.

Приведите конкретные примеры
Конкретные примеры приведены в книге Гради Буча :)
какого хрена эти авторы считают что имеют право поучать, какие методологии использовать, если сами толком не научились программировать даже процедурно?
Очень сильное заявление, ты не находишь? Чем трепаться здесь по поводу и без повода, лучше прочитай эти книги еще раз и просмотри свои крупные проекты ( если они есть ). Сколько кода можно было уменьшить, если воспользоваться готовыми классами контейнеров, готовыми алгоритмами...либо спроектировать эти классы, подстроив их под свои нужды. Как можно было увеличить гибкость и расширяемость проекта... Какой проект легче сопровождать?
Все авторы, иллюстрируя "преимущество" ООП над процедурным берут примеры в которых все переменные глобальные. Это называется макаронное программирование, а не структурное.
Кто такие ВСЕ авторы, и где ты нашел "ВСЕ" глобальные переменные?? ВСЕ(:) эти книги я тоже представь себе читал :)
Напоследок...Прочитай до коллекции "Дизайн и Эволюция С++". А потом покажи мне то место, где автор рекомендует испольщовать С++ ТОЛЬКО для ООП. Ди и в целом, никто никого не заставляет ни на что переходить.
Спутанный немного ответ, впрочем как и вопрос.

Были у нас лабы по компьютерной графике, в которых нужно было написать некоторый аналог paint'а. Делать это предлагалось на MFC. В каждой следующей лабораторной к программе добавлялись новые возможности: установить цвет, вид штриховки и так далее. При одинаковых функциональных возможностях, текст моей программы написанной на ассемблере был 30K, а у тех кто писал на MFC 60-70К. Да и времени на ее написание было затрачено столько же, сколько и у тех кто писал на MFC.(если не меньше)

Toxic
А что касается всяких OCX то если бы они были заточены под ассемблер то и использовать их было бы также просто.

The Diver
>Сколько кода можно было уменьшить, если воспользоваться готовыми...

Несомненно. Но в природе нынче более распространены библиотеки с "процедурным интерфейсом", чем иерархии классов, не так ли?

>Кто такие ВСЕ авторы, и где ты нашел "ВСЕ" глобальные переменные??

>прочитай эти книги еще раз...

Угу... Берем с полки Гради Буч "Обьектно-ориентированный анализ и поектирование..." второе издание, Бином, Невский диалект. страница 45

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

Ну как? Если это описание похождений автора, как не улыбнуться его мастерству?

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

Еще одно "обтекаемое" утверждение. Смотрим на предыдущей странице список языков программирования третьего поколения... Не правда ли, большинство из них хорошо известны как строго-типизированные?

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

Вот оно! Автор берет на себя смелость и ответственность сравнивать ОО языки лишь с первым поколением, действительно имеющим лишь примитивные механизмы для разработки крупных проектов.

captain cobalt
Сразу хочу заметить, что OOP никогда не претендовало на звание идеальной концепции программирования. OOP имеет ряд противопоказаний, побочных эффектов и т.д. НО ставить под вопрос целесообразность OOP, как такового... Я не хочу вас обидеть, поэтому ограничусь рекомендацией почитать B. Meyer (в добавок к вышеприведенным вами авторам).

Приведите конкретные примеры, иллюстрирующие преимущество ООП. Или программы, которые на ООП программируются проще и быстрее.
Первые версии AutoCAD не использовали OOP. Когда программерам из AutoDesk пришлось осуществить переход 2D -> 2.5D (а потом и 3D), они практически переписали всю программу с нуля! Далее последовал переход MS-DOS -> Windows, который не спровоцировал особого травматизма, ввиду того, что функциональный "kernel" приложения был эффективно изолирован от пользовательского интерфейса через инкапсуляцию OOP. Думаю, подобных примеров и так полно в книгах.

captain cobalt:
не стоит утверждать о вкусе устриц не пробовав их. Есть задачи, где применим только объектный подход. Есть задачи, где применим только процедурный подход и т.д. и т.п.
Каждый метод имеет свои недостатки, но и для каждого метода есть круг задач, где он (метод) будет идеальным решением. И глупо говорить, что для одного метода этот круг шире чем для другого.
Далее - если ты под ООП подразумеваешь просто организацию классов, то естественно твое представление ООП весьма убого. Дело в том, что классы просто помогают группировать функции. Не больше. Это получается просто аналог модулей, т.е. "те же яйца, только..."
Смотри на ООП с точки зрения реализации абстракций, виртуальных методов и виртуального наследования, а так же шаблонов. О чем и хотел сказать автор отрывка, который ты привел.
Простой пример тому:
1) для виртуальных методов - разделение уровней абстракций.
т.е. мы имеем базовый класс CShape, у которого есть метод к примеру Draw. - т.е. CShape может только рисовать себя.
Но сам класс - есть абстракция. Т.е. Draw не реализован в нем. Но мы уже знаем, что все, что рисуется - наследуется от CShape.
Далее. У нас есть CLine - который тоже Shape по своей натуре. Следовательно - мы наследуем его от CShape, и реализовываем в нем Draw.
Далее, самое главное - все объеты теперь можно нарисовать с помощью унифицированного интерфейса - CShape::Draw.
Следовательно если нам нужно иметь некий массив объектов, которые нужно рисовать, то мы делаем это так:
CShape ** shape_arr = new CShape*[1024];
И далее
CLine line1;
CLine line2;
shape_arr[1]=&line1;
shape_arr[2]=&line2;
И при этом - программист не знает, да и ему и не нужно знать - какой объект там в shape_arr находится.
и рисуется это все просто :
for (int i=0;i!=1024;i++) shape_arr[i]->Draw();
Вот в последней строчке и есть вся прелесть ООП - а именно - тебе похрен что туда засунули. Там потомок CShape , и тебе не нужно беспокоится о том, чтоб его как-то по-особому нарисовать - ты ему просто говоришь - Draw. А через vtable будет вызван конкретный метод Draw для конкретного класса.

Пример номер два : шаблоны.
тоже есть весьма великая вещь, т.к. она позволяет избежать большой иерархии наследования, как это сделано в паскале от TObject. По той причине, что шаблоны разбираются на этапе компиляции. Т.е. они чем-то напоминают директивы препроцессора. Опять же . Приведем пример :
Есть функция сортировки.
для неё нужно следующее - определить какой из элементов больше. Но , согласись, в случае со String и в случае с Int это будут разные функции сравнения.
Следовательно мы делаем всего лишь _один_ блок кода, кторый будет сравнивать . Мы реализуем классы с методами "operator >" и "operator <" и подставляем их в шаблон.

ОО языки
Я таких не знаю, я знаю языки, поддерживающих ОО подход.как не улыбнуться его мастерству
А как насчет Rational Software и Booch Components?

rst
Спасибо. Я в достаточном обьеме знаю ОО методологию и язык С++.
А CShape это пример полезного применения ООП? :)
А шаблоны, строго говоря, это механизм не ООП.

The Diver
>А как насчет Rational Software и Booch Components?

Да, это пример "правильного" использования ООП.
Хотя попытка запихать алгоритмы в классы выглядит странно...

А CShape это пример полезного применения ООП? :)
Именно.
И опять же - не сам CShape, а рассмотренный на его базе механизм абстракций.

The Diver
ОО языки
Я таких не знаю
Это не значит, что таких нет. Smalltalk - вообще нифига кроме ОО не поддерживает :) Кажется, с него ООП и началось...

The Diver
>Очень сильное заявление, ты не находишь?

А что еще можно сказать, когда мне фактически говорят:
"ООП это круто потому что оно инкапсулирует данные"?
Все переменные обьявляют глобальными лишь когда только начинают учиться программировать...

rst
>Смотри на ООП с точки зрения реализации абстракций, ... виртуального наследования

Так ведь на то есть программирование "на основе абстрактных типов данных"...
Кстати, "в детстве" мне казалось что наследование нужно для того, чтобы можно было изменить базовый класс, и это изменение тут же отразилось бы в иерархии. А вот классики пишут, что ничего подобного, базовый класс фиксирован и изменения нужно вносить путем наследования. И с тех пор у меня тоже остался неразрешенный вопрос: стоило ли огород городить? Того же самого можно добиться путем агрегации (использования одного типа данных в качестве составной части другого). Имхо, более читабельно, и, между прочим, одинаково представляется на машинном уровне.

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

Quantum
>Думаю, подобных примеров и так полно в книгах.

Да, и в моей практике тоже. Но мне ВСЕГДА удавалось изящно инкапсулировать данные в локальные переменные, параметры функций и статические [термин языка си] переменные модулей. Вообще, такое "ядреное программирование" действительно мощный и симпатичный мне подход. А если в ядре оставить лишь минимум функций, а основную функциональность "отложить на потом", то приходим к идее, которую можно назвать "плагиновая архитектура". Между прочим по ней выполнены флагманы во многих отраслях современного программного обеспечения. Например, FAR manager... "грубый процедурный интерфейс" плагинов... и никаких гвоздей... :)

Я разделяю подход rst(Есть задачи, где применим только объектный подход. Есть задачи, где применим только процедурный подход). Универсальных(во всем) средств не существует. Для каждой задачи есть наиболее оптимальное решение с точки зрения эффективности.
Есть задачи, в которых ассемблер блистательно опережает все мыслимые и немыслимые HLL, но ведь есть и такие, в которых лучшим вариантом бутед туповатый QB.

captain cobalt:
Жизенные примеры тебе ?
Смотри :
1) MAPI
2) CDO
3) GDI+
4) по поводу не-микрософт - QT lib;
И соответсвенно продукты:
1) KDE - он весь и полностью объектно-ориентированный. И все программы под KDE используют ООП. Т.к. сама среда - ООП.
2) GNOME - тоже самое.
3) Java - это конечно отстой, но я думаю там сидят далеко не идиоты, если SUN зарабатывает миллионы долларов. Не так ли?
4) COM.. Как много в этом слове.. Написаны сотни тысяч продуктов, которые используют ООП на базе COM.

Ещё продолжать?
И вообще - достало.. Ещё один инициатор Holy War блин.

P.S. - до того, как меня достало работать на "дядек", я работал несколько лет в компании, которая имеет достаточно известное имя, и слишком хорошо знаком с процессом под названием Enterprise Development. Так вот, могу тебе сказать - ООП очень сильно сокращает затраты на реализацию, и сопровождение продуктов. По поводу "класса" продуктов - от 500К до миллиона строк, комманда девелоперов - 8 человек, время разработки - 2.5 года. Если у тебя более широкий опыт - дайте пожать вам руку.
P.S. - продукты , которыми я занимлся когда там работал : http://www.aelita.com/products/EMW.htm
http://www.aelita.com/products/DMW.htm
http://www.aelita.com/products/EMM.htm
http://www.aelita.com/products/SCW.htm

captain cobalt
А я вот говорю про конкретный CShape. Вряд ли он имеет практическую ценность в реальных приложениях.
Тогда на чём, по-вашему мнению, построено большинство графических редакторов 2D и 3D (AutoCAD, Solid Edge, Corel и т.д. и т.п.), редакторы блок-схем, всякий САПР? Прграммы моделирования/анализа электронных схем? Класс там не CShape называется, но построен по абсолютно схожему принципу.

Так ведь на то есть программирование "на основе абстрактных типов данных"...
Некоторые считают его праобразом ООП, хотя, IMHO, оно ООП и есть.

Да, и в моей практике тоже. Но мне ВСЕГДА удавалось изящно инкапсулировать данные в локальные переменные, параметры функций и статические [термин языка си] переменные модулей.
Зачем зацикливать тему на инкапсуляции данных? В ООП также реализовано наследование, полиморфизм, абстракция вообще, ... Вы или не те книги читаете,... или неправильно понимаете авторов,... или недочитываете :-) А может Вам просто никогда по-настоящему и не нужно было использовать ООП, но это не значит, что софтверные гиганты ерунду проповедуют в среде своих разработчиков.