Мало что из статьи запоминается, кроме того, что автор "ушел изучать поэзию в 1995 году". А так - банальности одни.

Да вообще ни о чем статья, просто ни о чем.
Скажем так, в ней технических деталей нет, есть только эмоции.
А вот с эмоциями я, как ни странно, согласен.
Мафия идеологов ООП уже начинает доставать, совсем как правительство Путина.

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

Я как-то был на семинаре Криса Дейта - который SQL создавал со товарищи. Его атаковали все время сторонники ООП в базах данных. Он отмахивался - SQL - это минимальное пространство, в нем все можно, стройте ваш ООП выше. Честно говоря, тогда я тоже считал его упрямцем (он такой и есть, в 1999 году говорили, что у него не было электронной почты, только факс), но когда вскоре после этого засел в большой SQL-проект (написание провайдера для OLE DB), понял, что он во многом был прав, и, будь SQL объектно-ориентированным, мне бы это только мешало, поскольку я компоновал другие объекты по-своему.

Но парадигма ООП, конечно, мощная. Никуда не денешься от нее.

>Но парадигма ООП, конечно, мощная.

Можете перечислить что в ней мощного?

Я могу.

Если не сложно...

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

Это издержки обучения. Как "убивать плохо", "руками в розетку лезть нельзя" и так далее.

То есть начинающий, следуя этим правилам, большой беды не причинит. А когда вырастет - сам всё поймёт. Ну или не поймёт...

Модульность далеко не единственная важная вещь в разработке ПО. Чем еще может похвасть ОО?

>Для этого и нужны инкапсуляция, наследование и полиморфизм.
>К сожалению, многие почему-то считают, что инкапсуляция и прочее нужны сами по себе.

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

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

А полиморфизм не устраивает? Для примера.

"Огласите весь список".

Касаемо полиморфизма: если ваше определение не отличается от этого (http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?query=polymorphism), хотелось бы услышать доводы что полиморфизм присущ только ООП.

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

Дык, пролог -- это ж встроенная либа, реализующая метод резолюции. Возьмём любую такую либу на java (их несколько) и получим те же 20 строчек. Ну, может, больше, из-за не слишком удобного синтаксиса при обращении со списками. (Кому важно именно 20 строчек, то же самое проделает на python-е :)

Интересно также читать обсуждение статьи на LOR.
Такое впечатление, что туда завезли два мешка плана.
Один товарищ там назвал ML императивным языком.
Другой говорит, что методы get.../set... это нарушение инкапсуляции.
Убивать, убивать, выживших - обучать в институтах по новой.

LOR? Ты бы еще damochka.ru читал :)

А там тоже ООП обсуждают?

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

Порванный?

get/set действительно частенько не более чем нарушение инкапсуляции. Могу найти пару статей Alan Golub на эту тему — если не бросаться сразу же в спор, всё поймёшь.

С другой стороны, это такое же "откровение", как и утверждение "ООП не панацея".

Why getter and setter methods are evil
http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html

Why extends is evil
http://www.javaworld.com/javaworld/jw-08-2003/jw-0801-toolbox.html

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

Да, да, а еще правила Лисков (иди как там ее звали), why public inheritance is evil, etc.

ага давай дискуссию по поводу геттеров и сеттеров устроим :)))) я тоже могу ссылок наприводить и аргументов. Ты еще камрада Мартина вспомни с его концептом паблик переменных :)...для value objects правда, но тем не менее

Статья и в самом деле слабенькая. Автор пишет в одном ряду "Java, C++", хотя объектная модель у них разная, да и даже во времени между ними пропасть.

Да ну -- разная. На глобальном уровне -- одна. Вот у JavcScript, SmallTalk и C++/Java -- Разная. На фоне этих отличий разница между C++ и Java, в общем-то, косметическая.

Лев прав, объектная модель у них разная, но классически Java все используют как C++.
Из Java не получится сделать ни Smalltalk, ни Objective C.

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

...а мужики-то и не знают!

Да, статья, конечно, нелепа. Но вот несколько интересных мыслей и фактов:
(1) "инкапсуляция, полиморфизм, наследование" -- это уже позднейшее искажение идей Алана Кея (создателя СмоллТолка что важно в данном контексте, а так же графического интерфейса, ноутбука и много чего еще, что тут не важно). причем искажение обедняющее. Его триада была более мощной.
(2) Мысль, на которую меня навел Луговской, человек неординарный, хоть и наредкость одиозный: ООП нужен и используется там, где нет нормальной мат. модели. Т.е., там, где мы пока ничего не умеем. Как только мат. модель появляется -- ООП идет в пень. Пример положительно-положительный -- тот же самый SQL. Пример отрицательно-положительный -- GUI, где есть одни общие рассуждения и ООП цветет и пахнет. Примеров *-отрицательных я найти не смог.

Кстати, а Луговский, наконец, построил функциональную модель для GUI? А то он сто лет брызжет слюной по поводу прямо-таки фантастической сращиваемости GUI и функционала, но дальше этого брызганья слюной дело как-то не идёт.

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

>GUI, где есть одни общие рассуждения и ООП цветет и пахнет

Отсюда подробнее, пожалуйста. А то мне, глядя на пару мейнстримовых GUI-фреймворков (VCL да тот же NET.WinForms), почему-то делается очень грустно. Или это разработчики Microsoft и Borland не владеют сакральным знанием ОО?

Не владеют.
Взгляните на Cocoa Application Framework.
Или же на NextStep GUI - это практически одно и то же.

Можно в двух словах чем Cocoa так хороша в плане GUI в реальной работе? А то я больше часа погуглил, но преимуществ не понял.

p.s.
Про GUI Next'а когда-то читал -- очень красивая идея, жаль не довелось нигде живьём увидеть ни Next ни MacOSX.

Можно.
Там все нормально устроено, крайне понятно даже мне.
Я считаю, это немалое преимущество.

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

А по моему опыту - главное чтобы дублирования кода не было, а какими средствами это достигается - не так важно.

А разгадка одна - в "объектной парадигме" не было ничего нового.
Привязка "концептов" Платона/Аристотеля к старым добрым Modula.