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


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


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


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


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


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



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

djamshud, понятно, что Вы (теперь) ратуете не против ООП а против его неправильного и неоправданного использования. С этим никто не спорит.
Только доводы Ваши местами странные. Как будто есть обида на коллег, которые используют неправильно и не к месту. Тогда не надо обобщать. И тем боле привлекать "светил", которые говорят не о том, что Вы, а о другом. А понимают, несомненно, много больше, чем говорят...


Жюль Верн. "Необыкновенные приключения экспедиции Барсака"