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

Список терминов:
ООП - объектно-ориентированный подход в нынешних мэинстримных инкарнациях, соответственно и ОО-проектирование и ОО-программирование, по контексту обычно понятно.
Dataflow programming - подход к программированию, когда большую часть внимания уделяют алгоритмам управления движения и модификации данных. Алгоритмы собственно обработки либо стандартны, либо реализуются в виде подпрограмм. У данного подхода очень велика доля повторно реально используемого кода.

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

Адепты часто пропагандируют максимальное абстрагирование при решении поставленных задач. Если мне нужно съесть яблоко, зачем абстрагироваться до поедания сферических фруктов в вакууме? Мне это не поможет съесть ни яблока, ни ананаса.

В обоих случаях люди пытаются решить задачу обобщенно, что несомненно хорошо, но выбирают инструмент, которому они обучены, но который для этого совершенно не предназначен. Куда более удобно и естественно для человека (а не программирующего человекоподобного робота) это решается благодаря функциональному и dataflow подходам. Причем обработка (потоков) данных - основная задача при программировании почти всего и на всех этапах.

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

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

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

Полиморфизм. Удобен при использовании на низком и среднем увровне. На высоком непригоден в виду того, что взаимодействие, особенно в перспективе дальнейшего развития, между сущностями может быть абсолютно любым. Частично спасают мета-программиорвание и паттерны.

Когда я использую ООП.
1. Когда естественная сущность элегантно представляется в виде объекта и нескольких обрабатывающих его методах. Этакий "С с классами".
2. Когда писал (и сейчас хочу сильно пропатчить) библиотеку контейнеров. ООП в данном случае весьма хорош: на низком уровне не используется, а вот в средний - что составляет большую часть задачи - он прекрасно вписывается.
3. Когда писал ядро компилятора. Опять же в основном программирование происходило на среднем уровне, а вся информация о типах и лексемах гонялась по RTTI. Уже при его программировании я осознал удобность датафлоу и весь синтаксический анализатор приспособил именно для такой обработки последовательностей лексем.

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

Ну и мнение светил: http://citforum.ru/gazeta/165/

Это сообщение отредактировал(а) djamshud - 27.9.2010, 15:42

А. Вы предлагаете :
1. отказаться от ООП в пользу процедурного программирования
2. -//- в пользу некоего другого стиля ? тогда какого ?
3. не поклоняться ООП и использовать его лучшие стороны.
4. или что то другое ?


Б. что лично Вы видите плохого в ООП ?

3, поэтому когда-то 1, когда-то 2.

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

тогда еще уточняющий вопрос, так Вы против ООП или против С++ реализации ООП ?

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

Добавлено через 2 минуты и 33 секунды
mes, лично я не против ни С++ с его реализацей ООП, ни ООП вообще. Я за то, чтобы это перестало быть панацей. Сейчас в современном программировании складывается ситуация, что дураков заставили богу молиться, а они лбы себе расшибают.

Добавлено через 3 минуты и 19 секунд
ЗЫ. За решетку угодили фекалии:).

когда человек что-то не понимает, он это отвергает.

Не утверждаю, что ООП наше все  (и не буду утверждать, ибо имел дело с задачами, где ООП не место), но он занял свою нишу, доказав состоятельность. 

Vasay, пруфы, пруфы в студию! Я привел пруф с кучей пруфов внутри. За "непонимание" незачет - в статье рассказывают о мнении (обоснованном!) светил программирования.

 не согласен ни с "костылями" , ни с "напрямую следующими"



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


хочу уточнить, что "С с классами" это более чистое ООП, чем текущий С++, в котором задействаны и другие подходы.. 


ни стл, ни буст не являются инструментами  ООП как таковые.


учитывая подправки, не понятно , что подразумевается под "это " . Большинство сказанного не относится к ООП.


так может проблема все таки в дураках ?


Добавлено через 10 минут и 2 секунды

боюсь насчет "С с классами" они тоже не лучшего впечатления )

mes,

>не согласен ни с "костылями" , ни с "напрямую следующими"

Напрямую следуют - потому что все придумано для ООП. Костыли, потому что современное ООП без них не может.

>не было бы ооп, промывали бы чем нибудь другим..

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

>хочу уточнить, что "С с классами" это более чистое ООП, чем текущий С++, в котором задействаны и другие подходы..

Именно поэтому я его и использую.

>ни стл, ни буст не являются инструментами  ООП как таковые.

Стандартная библиотека, особенно ее развите за последние лет десять, и буст - это еще одни костыли, на этот раз для поддержания убого ООП, заложенного в С++. Стл - это библиотека алгоритмов (и может быть немного контейнеров), она лишь толика стдлиб.

>учитывая подправки, не понятно , что подразумевается под "это "

"Это" - собственно современный ООП (я все же в основном смотрю с позиций С++) и вся система палок и веревок для того, чтобы этим можно было пользоваться.

>так может проблема все таки в дураках ?

Проблема в тех, кто управляет;)

Добавлено @ 23:43
>боюсь насчет "С с классами" они тоже не лучшего впечатления )

Так я не отстаиваю их позиций, у меня свое мнение:). Хоть во многом и схожее.

Да кстати, для тех, кто не читал, но осуждает: там никто не говорит о полном "запрете" ООП.

Это сообщение отредактировал(а) djamshud - 26.9.2010, 23:43

Какой тебе нужен пруф? большинство прикладного ПО пишется с применением ООП. 




Если бы все "Светилы" были бы согласны с тем что ООП не нужен - его бы не было .

Добавлено через 2 минуты и 49 секунд
djamshud, 

Так я не понял, вам не нравится ООП, или его реализация в С++ ?

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


ООП патерны лишь малая толика от общего числа паттернов



так все таки претензия к ООП или к С++ ?! ведь против православного ООП ничего против не имеете.. 



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


современный С++ далек от современного ООП.. или для Вас все что с классами то ООП ? 


решается соблюдением заповеди: не сотвори себе кумира.


Добавлено через 2 минуты и 49 секунд

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

Vasay, я на ночь глядя прочитал совсем не то, что вы написали:) Пруф не надо.

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

>Если бы все "Светилы" были бы согласны с тем что ООП не нужен - его бы не было .

А кто говорит про всех? Я говорю про отдельно взятых светил, которые не троллинга ради хаят ООП. Незачет за то, что вы считаете их непонимающими.

>Так я не понял, вам не нравится ООП, или его реализация в С++ ?

Мне не нравится современные инкарнации ООП в С++, Яве или С#. С последними двумя я не сильно знаком, но из того знакомства, что было, да и по многочисленным публикациям я делаю вывод, что в них ООП создавалась под впечатлением плюсовой реализации, с какими-то уточнениями и другим синтаксисом.

вот хоть понятно что.. а терь можно узнать пару тройку фактов почему ?

Как раз в тех двух областях, в которых я получал свое образование (и некоторое время работал) - ООП не нужен    (и когда-то я тоже плохо понимал - зачем мне нужен этот ооп)



Первое впечатление, обычно ошибочно. В данный момент Вы занимаетесь именно тем, что "отвергаете то чего не понимаете".

Это сообщение отредактировал(а) Vasay - 27.9.2010, 00:14

mes, камень не в ваш огород.

>ООП патерны лишь малая толика от общего числа паттернов

Все, что я видел - так или иначе крутится вокруг ООП. Можно ссылок на большую часть?

>так все таки претензия к ООП или к С++ ?! ведь против православного ООП ничего против не имеете.. 

Так православный ООП и его нынешние мэинстримные инкарнации - небо и земля. И я еще раз повторяю: я не против никакого ООП, я за то, чтобы средства использовали по назначению.

>буст костыль, но не для поддержания ООП.

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

>современный С++ далек от современного ООП.

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

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

Не вижу больших разногласий и запостил ссылку на нее, потому что разделяю большую часть выдвинутых там позиций. В стартовом сообщении я свое ИМХО высказал предельно ясно. Сейчас мэинстрим для решения почти любой задачи: провести системный анализ, на его основе разработать объектно-ориентированную модель с изначальным уклоном в реализацию на мэинстримных С++/С#/Java ну и собственно набыдлокодить это чудо-юдо.

Добавлено через 11 минут и 24 секунды
Vasay, а я работаю в тех областях, где ООП с радостью применяют. И сам применял, пока не понял, что он только вредит. Статистика, анализ, моделирование, в частности - имитационное распределенных процессов.

mes,

>а терь можно узнать пару тройку фактов почему ? 

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

Доброе утро.

Про IT в образовании вообще отдельный вопрос, по крайней мере в этой стране.

п.с. Я за процедурное программирование и функциональный подход.

А власти скрывают!


"C с классами и наследованием" реализует все три основополагающих принципа ООП, которые вбивают в мозг студентам айтишных специальностей. Хочешь мастдайнуть собственные приёмы программирования?


Заносите критерии православности ООП и проблемы нынешних его инкарнаций в студию. Если не против ООП, то что призывает мастдайнуть название темы?


И что плохого в использовании ООП подхода в программировании?

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

пример
ядро linux - сплошное ООП и выглядит это все логично, красиво, расширяемо
мне достаточно

Пост был пропатчен. Shaggie, заголовок лишь для провокации флейма. Это ж раздел с холиворами!

Добавлено через 11 минут и 54 секунды
А, забыл. Православный ООП - это тот, что отписан в bluebook (это тот блюбук, который про смолток 80).

Главное, чтобы ООП не лишали здравого смысла как например это сделли в С#. Вот какого фига оттуда убрали локальные функции? Почему они в Делфи есть а в С# нет? В результате приходится подпрограммы выносить на уровни метода, а это логический ###.

Это сообщение отредактировал(а) Vex - 28.9.2010, 10:15

Зато в Nemerle есть локальные функции   

A5uKa, 


я про него прочитал это какой-то рак мозга )

Добавлено через 39 секунд
а в джаве тоже нет локальных функций?

Почему ?

djamshud, ИМХО, не надо было капитально редактировать первый пост, лучше бы накатал масштабный ответ и дал с первого поста ссылку на него, а то и вправду вся тема поехала.



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


   А есть ссылочка, где бы можно было про неестественность инкапсуляции высоких материй почитать?
Любой слой приложения имеет в подчинении совокупность интерфейсов низлежащего слоя, владение ими и порядок вызовов имеет смысл инкапсулировать в объекте, предоставив набор методов наружу. Даже будь это самый-самый высокий уровень, всё равно надо спрятать детали в вызове application.execute(), спрятав потроха.


Похоже, в команде программировать не приходилось? Чужой код поддерживать, собственный кому-то на поддержку отдавать? Быть ответственным за большую важную систему? Человеческий фактор нельзя недооценивать, а подход "Вам что, жалко?" не даёт гарантий в разработке.


Можно и без ООП с успехом запороть повторное использование. Лично моё мнение такое, что reuse кода и подход к программированию вообще слабо друг с другом коррелируют.


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


Дальше прекрасное:

Отлично, значит C по умолчанию ООП язык   


Библиотека контейнеров прекрасно пишется труъ-функциональным способом, ни капли не теряя в удобстве использования. К чему лишнее использование ООП, если оно тебе не нравится?


О, таки при работе над крупной задачей преимущество ООП внезапно было осознанно!


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

а каким боком они должны там быть. C# как бэ объектно ориентированный язык (и работа там строится на взаимодействии объектов, в отличие от того же С++ - который только это парадигму поддерживает. полагаю что  с дельфи песня та же.

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

Shaggie,

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

Ну и каким боком тут инкапсуляция вообще? Инкапсуляция != скрытие. Мы написали функцию, в ней низкоуровневая реализация. Что куда и с чем инкапсулировалось? Или мы будем называть инкапсуляцией написание любой процедуры?

>А есть ссылочка, где бы можно было про неестественность инкапсуляции высоких материй почитать?

Это мое имхо. Могу дать ссылку на первый пост:)

>Даже будь это самый-самый высокий уровень, всё равно надо спрятать детали в вызове application.execute(), спрятав потроха.

Какие еще потроха у высоких то материй?! На этом уровне занимаются спариванием сферических коней в вакууме.

>Похоже, в команде программировать не приходилось?

Как раз таки приходилось. И как раз таки убедился в полной непригодности black box-ов. Потому что иногда нужны перламутровые пуговицы. Отныне максимум - защита от дурака, т.е. protected на языке С++ и никаких private.

>Можно и без ООП с успехом запороть повторное использование.

ООП предоставляет куда больше возможностей в этом плане!

>Отлично, значит C по умолчанию ООП язык

Интересный вывод. "C с классами" - это C++, в котором максимум используется class для инкапсуляции.

>Библиотека контейнеров прекрасно пишется труъ-функциональным способом, ни капли не теряя в удобстве использования. К чему лишнее использование ООП, если оно тебе не нравится?

Так как она писалась для использования в C и C++ проектах, использовать труъ-способ - это как вырывать гланды через жопу.

>О, таки при работе над крупной задачей преимущество ООП внезапно было осознанно!

Это вовсе не крупный проект. Пара тысяч строк. И как я писал, ООП там используется в основном для реализации dataflow и интерфейса к нему.

>Программирование многогранно, есть задачи где использование ООП подхода излишне, но это не повод объявлять ересью всю индустрию в целом. 

Использование ООП излишне в большинстве случаев. Многочисленные адепты упорно пихают его всюду. Различные "кусочки" ООП пригодны во многих случаях, а вот весь комплекс ООП - это прибитый гвоздями сам к себе позор. В отличии от труъ-ООП он черезчур статичен, а динамичность ему придается лишь многочисленными костылями.

 внимательный просмотр паттернов позволит понять, что
1. многие из ООП патернов применимы также и во многих других концепциях. например Делегат, Стратегия, Контроллер, Итератор..
2. некоторые паттерны в ООП реализованы как средства языка и поэтому фактически не могут быть ООП-патернами, например: Полиморфизм, Наследование
3. есть паттерны определяющие архитектуру устройства:
плагин, сервер/клиент 
4. паттерны взаимодействия и обмена данных
точка-точка/ точка-звезда, удаленный вызов, база данных, файловая ситема
.
..
... и т.д.
(возможно в высшесказонном есть мелкие недочеты, но неохото напрягать голову сейчас.. главное суть в том, что паттерн это не технология ООП, а технология, которую можно выделить и описать)

Добавлено через 1 минуту и 30 секунд

но статические же методы оставили ?!.. так вроде там и статические классы даже есть..



Это сообщение отредактировал(а) mes - 28.9.2010, 20:20

Ну так это не проблема инкапсуляции, а кривых рук... 





имхо повторное использование к этой теме вообще отношения не имеет.. 


имелся ввиду процедурный стиль ?


некоторое удобство теряется из за незнания контейнера как управлять жизнью объекта и создавать копии..


нет. Инкапсуляцией прежде всего называется сокрытие данных, а не сокрытие процедур. 
Вобщем для начала неплохо было бы ознакомиться с АТД и понять его суть и преимущества.. 


нда.. как связаны black box и перламутровые пуговицы.
интересно насколько по Вашему быстрее и удобнее была бы работа, если бы поле m_size  у string было бы public.. 


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



не понятно о чем тут.. 


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


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

Добавлено @ 21:07

вот на С++



Это сообщение отредактировал(а) mes - 28.9.2010, 21:08

Vex, просто для справки - ты когда писал (или пишешь) на дельфи - ты придерживался процедурного или объектно ориентированного программирования? 



OMG!

Согласен, точнее будет "сокрытие <- инкапсуляция"   


Давай напиши одну единственную функцию, которая умеет открывать/закрывать системный COM-порт, принимать и посылать через него байтики, всячески им руководить и буферизовать данные, при этом не вываливая наружу сам порт, всё его состояние и вспомогательный функционал. Ну даже совокупность функций, жонглирующих переменными. И внезапно окажется, что всё это может быть удобно (sic!) инкапсулировано в объекте.


Интересная, кстати, работа, я бы на это посмотрел и даже поучаствовал (хинт: смотри поле "где" в окошке информации о пользователе форума). Однако грамотное спаривание подразумевает работу интерфейсами, и при правильно спроектированной архитектуре можно подменить один сервис другим, ни капли не меняя в остальной программе. Это и есть инкапсуляция. Примеры можно нагуглить по словам Dependency Injection Framework и Inversion of Control.


Ну можно же было использовать друзей!   
Ответь, пожалуйста, на один вопрос - а почему тогда не public? Зачем эти странности с правами доступа, если самому же их приходится хитрым противоестественным образом обходить?


В чём проблема "комплексности ООП", почему кусочками оно хорошо, а целиком плохо, можно пример?
В чём проблема статичности "не труъ-ООП"? Статика и динамика - это вообще-то вопрос реализации типизации в языке, не более того. Какое несомненное преимущество имеет динамический язык по сранению со статическим, на твой взгляд?
В питоне типизация динамическая, он труъ-ООП язык? В лиспе типизация динамическая, он труъ-ООП язык? 




Имеется в виду именно функциональный стиль, примеры реализации контейнеров в OCaml, Haskell, Lisp, Erlang иже с ними. Но там другая среда исполнения, сборщик мусора сам следит за временем жизни хранимых объектов.

Я конечно дико извиняюсь за то, что лезу в столь высокоинтеллектуальные вопросы, не внеся свою лепту в дискуссию (неохота холиварить, мне здесь больше нравиться роль независимого зрителя с попкорном  )  но если речь все еще про C# то я не знаю где Вы его учили

и тоже самое на C++ - раз (по старому стандарту)

и два (по новому, смотрите скоро, на первом канале)

разве нужно что-то еще?

Это сообщение отредактировал(а) azesmcar - 29.9.2010, 09:35

а если дизассемблировать и посмотреть что на самом деле происходит   

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

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

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

Это сообщение отредактировал(а) azesmcar - 29.9.2010, 10:26

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


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


ну .NET 2 в прошлом, причем очень далеком. Там вообще много недоделок было, но со временем совершенствуют, раз уж говорим о C# то я полагаю надо говорить о последней версии (4.0).

Это сообщение отредактировал(а) smartov - 4.10.2010, 14:06

в таком случае:



обычно я этим и занимаюсь   

и это правильно, главное, что за это платят  

А если дизассемблировать код с дельфи - о, ужас, вообще функций нету  


Во-первых, дело не в .Net а в шарпе. Во-вторых, анонимные делегаты были во 2-ом ещё (шарпе). Лямбды и анонимные делегаты и есть "локальные функции".


Ну что-т тип такого (если что - яверы поправят красивее):


И самое интересное. И шарповские делегаты (неважно откуда они взялись - явный метод, анонимный делегат или лямбда) и даже яверная чисто ООП-шная реализация круче чем то, что в Дельфи, хотя бы потому, что это первоклассные сущности. А в дельфи для вложенных функций это неприменимо (по крайней мере в те времена, когда я это видел). Как написать на дельфи что-то вроде банального collection.Where(x => x > 5)?

А вообще - это полный оффтопик  

ООП не метод, а методология. Как любая методология для применения требует еще толику мозгов. И понимания, какую именно методологию полезно применять в конкретном случае. ОО это подход, и MAKCim абсолютно прав.
Что касается языков - дело вкуса. С++ поддерживает 3.5 парадигмы (0.5 на функциональное), что позволяет для большинства задач выбрать средство, оставаясь в пространстве языка. Выгода в краткости и читабельности кода.

А главное почти все присутствующие (в т.ч. молчаливо жующие попкорн) все отлично понимают, и просто развлекают друг друга... В надежде что придет серьезный mes и не даст умереть изначально тухлой теме)))

ЗЫ: Мнение А.Степанова насчет объектов/алгоритмов и сравнение с аксиомами/доказательствами имхо весьма слабая позиция. Если интересно, могу развить.

 он разве серьезный ?   


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

Добавлено через 3 минуты и 4 секунды

но где то в глубине все ж проглядывает здравая и интересная мысль.  наверно просто программирование еще не доросло до этого..


с удовольствием бы выслушал бы Ваше мнение по этому поводу.

Буду краток)))

Начну с тривиального постулата, что универсальных инструментов не бывает.
Помимо ОО подхода есть и множество других. На разных этапах и для разных частей задачи одни будут иметь преимущество перед другими, поэтому вопрос OOP vs Generic vs Functional vs ... вообще не стоит.

Степанов в интервью говорит:

Т.е. он считает ООП 
1. технически несостоятельным, потому что ООП пытается разложить мир в терминах интерфейсов, наследуемых от одного типа.
Думаю, "технически несостоятельный" - слишком сильное выражение в данном случае. Хотя бы потому, что ООП на самом деле не пытается это сделать: ОО подход - определить объекты, а потом искать у них общее - типы. Типы обобщаются - получается иерархия наследования. Никто не мешает обобщать по горизонтали - получаются обобщенные типы (вот вам и многосортные алгебры). Это уже не ОО компонент, но вполне в рамках общей методологии разработки систем - декомпозиции.

2. философски несостоятельным, потому что "все есть объект". "Даже если это правда, это не очень интересно: сказать, что все является объектом значит не сказать ничего."
Я лично ничего против объектной философии не имею, т.к. все действительно можно представить в виде объектов. Кто-нить приведет пример, когда это не так? Степанов тоже не может, иначе он сказал бы об альтернативе и не сказал бы "даже если это правда".
Представление в виде объектов, конечно, не панацея, но в целом вполне удобный прием абстрагирования.
Кстати, сравните с философией Unix "все есть файл". 

3. методологически неправильным, потому что сначала разрабатываются классы (читай - интерфейсы), а потом реализация. В качестве контрпримера приводится математика с аксиомами и доказательствами.
Это обвинение посерьезней, но оно в корне неверно.
Во-первых, наука не проектирование. Если бы в процессе проектирования мы ставили эксперименты и пытались на их основе вывести законы, проект никогда бы не завершился. В основе проектирования - анализ системы. В основе науки - анализ фактов и построение гипотез относительно структуры системы. Чувствуете разницу?
Во-вторых, начинать с реализации уместно только при разработке библиотек. Пропаганда применения разработки снизу вверх? Не верю, для сложных систем это тупиковый путь, т.к. слишком большие затраты на анализ полученных инструментов, их обобщение и интеграцию. Значит основная мысль такая: программа суть реализация алгоритма, а значит с него и надо начинать. Но этот алгоритм на самом деле конгломерат алгоритмов, соединенных причудливым образом. Нельзя объять необъятное. Поэтому начинается все с прецедентов использования, деления на компоненты и т.д. Т.е. применение принципа "разделяй и властвуй". Т.е. того, чему служит ООП.

Вот где-то так. Извините, что длинно, но и здесь не все поместилось))

Я кстати не верю, что Степанов действительно так считает. Скорее истина подавлена хорошим слогом ради красивого интервью.

Решил еще 5 копеек добавить для ясности.

Естественно, что разработать интерфейс можно лишь после того, как будет понятно, что должен делать алгоритм. Т.к. именно исполнитель диктует, какие исходные данные ему потребуются для решения задачи.
С этой позиции Степанов прав.
Но на самом деле адепты ООП и Степанов говорят об одном, ведь разработка класса (интерфейса класса) суть понимание назначения класса. И отнюдь не означает разработку интерфейса без понимания точки приложения усилий. Это просто игра слов: 
класс, решающий задачу, должен иметь следующий интерфейс... 
алгоритм, решающий задачу, должен получать следующие данные...

наченем с философии.. 

можно, но относительно.. 
Выражение "все есть объект"  должно накладывать некие отличительные признаки и обладать некоторыми гарантиями,
иначе ничем не будет отличаться от "не все есть объект" 
Страуструп в этом вопросе подерживает Степанова, и считает что "все есть void*", ибо делать все объектами несет дополнительные расходы и не согласуется с идеологией C++   

P.S.  некоторые моменты обострил специально для краткости.. 

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

ну так оно и накладывает. методология ООП не ограничивается сентенцией "все есть объект", ибо эта сентенция не есть методология, а в отрыве от прочего действительно является пустышкой.
вобщем мы щас начнем флеймить ниачём, выдумывая искусственные трудности словообразования.

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

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

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

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


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


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


с его ООА и ООП.. надо будет освежить в памяти о чем он там писал  в то время когда читал половину даже не понял 

  
освежить полезно... кстати последнее издание, несмотря на некоторые упрощения, имхо проигрывает первому, где примеры на разных ОО языках.
а про ООА (только А) есть отдельная книжица, хорошая, да куда-то задевал...
а, вот: С.Меллор, С.Шлеер. "Объектно-ориентированный анализ: моделирование мира в состояниях"

Shaggie,

>И внезапно окажется, что всё это может быть удобно (sic!) инкапсулировано в объекте.

Но излишне. Я не знаю АПИ работы с ком-портами, но в общем это все равно что-то вроде (или же можно привести к этому виду):

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

Окей. Пример почти реальный. Почти, потому что обощенный. У нас на работе случается переодически из-за мудовости одного из... заказчиков, скажем так. Получаем задачу. Месяц ОО-проектируем, рисуем юэмельки и вообще восхищаемся собственной крутостью. Оно и понятно - software designer-ы! В результате выделяем два "модуля": сущности А и Б. Они прекрасно знают интерфейсы друг друга и в целом хорошо ладят. Запрограммировали, все работает. Демонстрируем и узнаем, что было бы очень шикарно присобачить к системе модуль В, разработанный в каком-нибудь далеком сибирском селении в тамошнем НИИ. Пытаемся выделить какие-то общие интерфейсы для работы всех трех модулей - фиг там. Дальше два пути: либо еще раз жестко перехардкодить все три модуля, либо открыть Design Patterns и вхерачить десяток "фасадов", "мостов" или еще чего-нибудь из той же серии. В обоих случаях получается адская каракатица. А все почему? Потому что ОО-проектирование прибивает все сущности гвоздями друк к другу.

>Ответь, пожалуйста, на один вопрос - а почему тогда не public? Зачем эти странности с правами доступа, если самому же их приходится хитрым противоестественным образом обходить?

Защита от дурака - это в целом хорошо. Но из-за того, что частенько нужны перламутровые пуговицы там, где они не задуманы by design, случается, что приходится лезть в потроха реализации. Иначе повторное использование кода сводится почти к нулю.

>В чём проблема "комплексности ООП", почему кусочками оно хорошо, а целиком плохо, можно пример?

В его статичности. Кусочками можно реализовать динамичность, всем сразу - только забить крышку гроба на собственном проекте. Пример выше.

>В чём проблема статичности "не труъ-ООП"? Статика и динамика - это вообще-то вопрос реализации типизации в языке, не более того. 

В том, что мэинстримное ООП (проектирование в первую очередь) статично до усрачки.

>Какое несомненное преимущество имеет динамический язык по сранению со статическим, на твой взгляд?

В приведенном выше примере я бы просто пересоединил источники и назначения части данных, при необходимости динамически (не обязательно в рантайме!) добавил необходимые точки входов и выходов.

>В питоне типизация динамическая, он труъ-ООП язык? В лиспе типизация динамическая, он труъ-ООП язык?

Пистон не знаю. Лисп сам по себе тру, с его реализацеий ООП не знаком, но могу предположить, что труъ.

mes,

>внимательный просмотр паттернов позволит понять, что

Я понял, о чем вы. Цикл - тоже паттерн, да. Я более другие паттерны имею в виду, думаю, вы понимаете это. Их конечно можно применить и вне ООП, но там они нафик никому не нужны.

>Инкапсуляцией прежде всего называется сокрытие данных, а не сокрытие процедур.

RTFM. Это инкапсуляция:

Это не инкапсуляция:

Сокрытие данных - не свойство инкапсуляции, а ее дополнительная плюшка.

>нда.. как связаны black box и перламутровые пуговицы.

Еще как связаны. Если в классе "блузка" сделать private int color, то блузки с перламутровыми пуговицами не видать!

Это сообщение отредактировал(а) djamshud - 1.10.2010, 10:07

Строго говоря, "техническое" сокрытие - вообще не имеет отношение к инкапсуляции. Важно, чтобы нам было пофиг на эту структуру данных и мы работали с высокоуровневыми интерфейсами.

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

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




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



а статичности/динамичности чего идет речь ?


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


Добавлено @ 12:33


та же история 


Добавлено @ 12:46

и в чем тут вина ООП  ?! 


Это сообщение отредактировал(а) mes - 1.10.2010, 14:12

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

Добавлено через 3 минуты и 50 секунд

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

Добавлено через 5 минут и 20 секунд
ida вас бы поругала за такую организацию работ   

уж не уступает SmallTalk'у =)

http://ru.wikipedia.org/wiki/CLOS

Окей, допустим, POSIX-style. В функциях write и close хендл порта передаётся первым аргументом - вот тебе и доморощенная реализация объектов в языках, не поддерживающих ООП нативно. Инкапсуляция есть, полиморфизм (даром что реализован только за счёт того, что все устройства в *NIX являются текстовыми файлами) есть, наследование тут не нужно, но прикрутить не проблема. Выглядит как утка, крякает как утка...

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


Во-первых, пример абсолютно реальный и работающий. Во-вторых, несовместимость интерфейсов получилась не от ООП, а из-за организации работы, mes уже привёл хорошую аналогию.


Где забыли задумать пуговицы нужного тебе цвета в библиотеке работы с датами, и как часто приходится лезть в недра и править реализацию? Насколько упростится повторное использование кода, если вместо объектного стиля работа с датами будет реализована в процедурном?


Ничего не понял, а почему бы не использовать объектный подход по-необходимости? Никто не заставляет городить пятиэтажное наследование для каждого класса. Пример был умозрительный, можно примерно догадаться, в чём проблема, но так же можно в уме найти несколько красивых вариантов решения проблемы. Может лучше прямо кодом?


А проблема-то в чём?


Не вижу преимущества. Но так как я с абстрактным мышлением принципиально не дружу, давай лучше кодом.


То есть не "ООП маст дай!", а "статические ЯП маст дай!", это же совсем другой разговор получается   


Сейчас попробую осознать прочитанное в предыдущих постах: то есть, по логике djamshud, надо писать protected int color и наследовать NacreousBlouse от Blouse, чтобы иметь возможность сконструировать блузку с перламутровыми пуговицами? Получаем сразу несколько ошибок проектирования. Неудивительно, что понадобится
чтобы эта конструкция хоть как-то заработала.

Shaggie,

Я знал, что вы увидите в open/write/close ООП. Проблема в том, что вы готовы увидеть его везде. Я согласен, что к ним можно применить термины инкапсуляции и полиморфизма (а в сокетах - так еще и наследования!), но нужно понимать, что это АПИ создавалось без оглядки на сабжевый ООП. Плюс, не знаю, как с этим дела в c# и яве, но на С++ я не видел более удачных АПИ для работы с устройствами ввода-вывода: всюду получается хитрожопая каракатица, "вещь в себе".

>Во-первых, пример абсолютно реальный и работающий. Во-вторых, несовместимость интерфейсов получилась не от ООП, а из-за организации работы, mes уже привёл хорошую аналогию.

Я все же буду настаивать на том, что пример почти реальный, потому что сферический, без конкретики. :) К сожалению mes привел плохую аналогию. Так уж повелось, что меткие метафоры умеют делать единицы, mes наверное не из их числа. Ну или просто не срослось в этот раз... Проблема в том примере в том, что были выделены две высокоуровневые сущности типа "объект" (или "класс" - не суть в данном случае). И эти сущности знали только друг о друге и больше знать ничего не хотели, да и не могли. Все из-за того, что ОО-проектировщики от рождения привыкли, что "все есть объект". Если бы они знали, что "все есть данные и их обработчики" - такой проблемы просто не могло бы возникнуть. Впрочем тут я лукавлю: возникли бы другие проблемы:). Поэтому "все есть данные, их обработчики, процедуры и объекты; и может быть что-нибудь еще, по вкусу".

>Где забыли задумать пуговицы нужного тебе цвета в библиотеке работы с датами, и как часто приходится лезть в недра и править реализацию? Насколько упростится повторное использование кода, если вместо объектного стиля работа с датами будет реализована в процедурном?

В первую очередь хочется отметить, что реализация дат в объектном стиле, как и в случае с "файлами" - излишнее усложнение дальнейшего использования этих самых дат. Что касается пуговиц в датах, то они в них не нужны, пуговицы нужны в блузках!

>Ничего не понял, а почему бы не использовать объектный подход по-необходимости?

Именно! О чем я и толкую: использовать его по необходимости, а не искать в наркотическом угаре объекты там, где их нет.

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

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

>Может лучше прямо кодом?

Еще не существует (или я о нем не знаю) моего идеального языка, так что с моей стороны кодом не получится.

>А проблема-то в чём?

Статичность by-design и есть проблема. Проблема, что я не могу добавить объекту или классу еще один метод. Порблема, что я жестко привязываюсь к АПИ используемого объекта. Лишь частично это решается наследованием. В С++ очень многое из этого решается с помощью шаблонов и их спецификации: благодара этому язык хоть и стал намного динамичнее, но корень всех зол - проектирование - так и не сдвинулось с мертвой точки.

>Не вижу преимущества. Но так как я с абстрактным мышлением принципиально не дружу, давай лучше кодом.

Я все же попробую конкретизировать без кода. На этапе проектирование все высокоуровневые сущности выделяются в виде не объектов, а обработчиков данных (как в bash - "cat file.txt | grep -ie error | sed ... > out": cat, grep и sed в даном случае и есть те самые обработчики), и соответственно между ними не выстраиваются ОО-связи, а налаживаются каналы передачи данных. В таком случае НИИ уже создает не объект, который фиг знает как подключить, а обработчики, которые мы без проблем вписываем в общую схему движения данных.

>То есть не "ООП маст дай!", а "статические ЯП маст дай!", это же совсем другой разговор получается

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

>Сейчас попробую осознать прочитанное в предыдущих постах: то есть, по логике djamshud, надо писать protected int color и наследовать NacreousBlouse от Blouse, чтобы иметь возможность сконструировать блузку с перламутровыми пуговицами? Получаем сразу несколько ошибок проектирования. Неудивительно, что понадобится

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

>чтобы эта конструкция хоть как-то заработала.

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

mes, если вышеприведенным текстом я еще не ответил и на ваши комментарии, сделаю это позже - сейчас нет времени. Прошу прощения, что не заметил раньше.

Не стоит всех под одну гребенку )


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

ну и что в ООП мешает определить сущности ? есть объект-данные, есть объект-обработчик, есть объект-делегат...  То Вы против паттернов, а сейчас прямым текстом к ним толкаете... Проблема не в ООП а в том как его видит разработчик.. 


Это как раз остальные об этом толкуют, а Вы о 




А я могу   естественно объект должен предусматривать эту возможность и накладываются ограничения в рантайме..  Зачастую для подобной функциональности легче использовать скриптовый язык.. 

Только я Вас опять не пойму.. Вам нужно динамическое поведение , чего  Вы С/С++ выбрали, которые очень слабую поддержку этого имеют.. И опять же значит не против тех языков в которые это умеют ?


если в рамках языка, то в процедурном стиле это функции, а в ооп функторы - ощутите разницу


Ну и ? если для определенной задачи устанавливаете другой вид связи, то  все остальное в свалку ?!
 а понял !!  Вы считаете что при ООП объект grep должен знать об объекте sed ?
ну тогда неудивительно что Вы его противник  я б наверно тогда тож возненавидел бы 



Опять же проблемы понимания... Кстати паттерн называется Цепочка обязанностей 

.


Согласен, но не забывайте, что зависит от того в чьих руках эта система палок и веревок :
 один может повеситься, а другой покоряет Эвересты 
  

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

кстати. поскольку в open/write/close много общей алгоритмистики, обобщенное программирование тоже имеет место быть. потоки в C++ не верх совершенства, там есть что улучшить, но они - совокупность ООП и Generic.


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


Неправда. Давайте пример, выстроим.


Классу? Легко.

Объекту? Не нужно. У объекта уже есть задача, он ее решает. Другую задачу должен решать другой объект.
Приходишь домой, а там вместо жены усатый дядька. Это жена изменилась. Под влиянием местных условий. Конфуз...

Все-таки Вы чего-то не понимаете... Возможность "добавить метод" нужна ООЯ с объектами, но без классов. Javascript например. Smalltalk. Хорошо ли это? Нет. Потомучто грабли переносятся с компиляции на рантайм. С++ как раз хорош тем что строго типизирован.
Но... это все особенности реализации и к ОО относится постольку поскольку)))


ну нет, так нет. ради бога. а что там есть?


ЗЫ. Гляньте на Graph Boost Library. Там нету классов, но она яркий, хороший пример не только generic, но и ОО подхода.

Добавлено @ 15:04
конечно, ООП не подходит идеально для всех типов задач.
конечно, не каждый язык имеет все желаемые средства. например, нет в С++ мультиметодов
конечно, траншею можно выкопать алюминиевой ложкой.
конечно, изящно смотрится

однако имхо не менее изящно

где discrete один из базовых алгебраических классов

Да, ООП может порождать излишне длинные цепочки наследования, которые можно заменить приемами из других парадигм. Но эта критика ООП совсем не то, о чем говорите Вы

Это сообщение отредактировал(а) baldina - 6.10.2010, 15:05

mes,

>ну и что в ООП мешает определить сущности ? есть объект-данные, есть объект-обработчик, есть объект-делегат...  То Вы против паттернов, а сейчас прямым текстом к ним толкаете... Проблема не в ООП а в том как его видит разработчик.. 

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

>Это как раз остальные об этом толкуют, а Вы о

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

>А я могу  естественно объект должен предусматривать эту возможность и накладываются ограничения в рантайме..  Зачастую для подобной функциональности легче использовать скриптовый язык..

Опять вы про гланды через жопу, да еще и с ограничениями. Для этого языку вовсе необязательно быть скриптовому. А в том же скриптовом пхп этого, ЕМНИП, нету. Потому что при прикручивании ОО-части к языку опирались на все те же мэинстримные языки.

>Только я Вас опять не пойму.. Вам нужно динамическое поведение , чего  Вы С/С++ выбрали, которые очень слабую поддержку этого имеют.. И опять же значит не против тех языков в которые это умеют ?

Я не против никаких языков. Я против притягивания ОО-парадигмы (в первую очередь - мэинстримной!) туда, где ей не место. А это... почти везде. Сиси плюсплюс, потому что еще можно на Аде, больше ни на чем нам писать низя. Да и в большинстве случаев "С с классами" более чем хватает.

>>а этапе проектирование все высокоуровневые сущности выделяются в виде не объектов, а обработчиков данных
>если в рамках языка, то в процедурном стиле это функции, а в ооп функторы - ощутите разницу

Нет, это совершенно разные вещи.

>Вы считаете что при ООП объект grep должен знать об объекте sed ?
>Опять же проблемы понимания... Кстати паттерн называется Цепочка обязанностей

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

>Согласен, но не забывайте, что зависит от того в чьих руках эта система палок и веревок :
> один может повеситься, а другой покоряет Эвересты 

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

Как раз наоборот, в ООП это является (не знаю правильней слова) сутью...


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


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


Я согласен, что не следует притягивать куда не надо, но не соглашусь, с почти везде. 


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


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


нда.. А обработка событий в любом ГУИ ? таже цепочка обязаностей  Или применительно для обработки текста ? Так тут дело скорей всего в двух причинах 1. не сталкивались, 2. для такого выбирают другой язык.. 


т.е. нужно в языке иметь все возможные средства ?!


или наоборот на каждую задачу свой язык ?


опять ! при чем тут буст и стл когда они не "призваны" поддерживать ООП ?!


т.е. как я предполагал, пистолет-форму дали, чего ж еще надо то ! 


нашли кого причислять ООПешникам ) для него как раз рамки не писаны 



Так может бороться надо с вдалбливанием и леммингами, а не с ООП ?
а то что культура программиропванния еще не сформировалась, я согласен )