[philosophy] В чем заключается революционность перехода от функциональщины к ООП?

Фишка в том, что отдельную, четко абстрагированную сущность в ООП легче дорабатывать и использовать во многих случаях (ИМХО)

Наверное, вы хотели сказать «от процедурщины к ООП»? Ничего страшного, тут такие ляпы делают на каждом шагу.

Неужели те преимущества, которые предлагает ООП (полиморфизм, инкапсуляция, наследование), дают прирост в эффективности, скорости написания программ, понимания их работы и поддержке?

Да.

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

А вот тут еще две неточности. Лучше говорить не «функциями», а «процедурами»/«подпрограммами» (чтобы не было путаницы с Ъ-функциональными языками - вы же имеете в виду как раз процедурные языки), и не «объектами», а «классами, объектами, их свойствами, методами и их отношениями друг с другом».

Впрочем, даже если бы имелись в виду Ъ-функциональные языки, то вывод был бы таким же:
- ООП - выбор промышленного программирования;
- функциональные языки иногда проявляют себя в редких, чаще всего научных, задачах;
- процедурные языки сегодня являются либо матерым legacy, либо находят себя в embedded'е и системном программировании.

>Почему сейчас все кругом вопят про ООП

Вы из восьмидесятых годов пишете?

Соглашусь с предыдущим оратором про 80-ые годы, ибо...

Почему сейчас все кругом вопят про ООП и про его архиполезность и архиправильность?

...это, знаете, словно сказать «Почему сейчас все кругом вопят про интегрированные микросхемы, их архиполезность, архиправильность и архипреимущества над лампами, транзисторами и реле?»

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

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

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

>причем эту позицию он завоевал не благодаря маркетингу или еще какому буллшиту

Как раз таки благодаря.
Парадигме ООП хрен знает сколько лет - стоит вспомнить smalltalk, не говоря уже о симулах и пр.
Но популярность она набрала только вместе с C++ и Java.

> Но популярность она набрала только вместе с C++ и Java.

т.к. эти языки более практичные - первое это С с прибитым сбоку ООП, второе - целая платформа

>т.к. эти языки более практичные

я не думаю

Ну вот в википедии есть кое-что по теме критики ООП, со ссылками на некоторые работы. Цитата оттуда:

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

Инкапсуляция и так есть. А вот Полиморфизм и Наследование — по-настощему революционные вещи, позволяющие связывать код во время его исполнения, а не компиляции.

Представление актора Объектом, а не Процессом (Функцией) — ключевой вопрос расхождения парадигм. Таким образом в вершину угла ООП ставится расширение возможностей объекта (актора) как по линии изменчивости (полиморфизма), так и по линии дополнения (добавления новых методов).

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

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

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

> Вопят, как вы изволите выражаться, как раз адепты новомодных (хоть иногда и с 50-летней историей) функциональных языков.

Эти новомодные функциональные языки с 50-летней историей, как ни странно, насквозь объектно-ориентированные.

Что ты мне это говоришь?

Перепутать функциональный и процедурный подходы - это сильно!

По теме. Бесспорно, в ООП есть хорошие идеи. К тому же, оно довольно таки старо (Симула) само по себе. Вопрос в уместности применения того или иного подхода. Иногда ООП дает пользу, иногда нет.

Сухой остаток немножко другой.

ООП, если хорошо отжать, даёт человеку ad-hoc полиморфизм. Который ему не нужно реализовывать ручками (как правило). Более, по сути, ничего. Наследование, как правило, реально нужно только для реализации интерфейсов (или же ошибочно применяется как замена агрегации), а инкапсуляция вообще по уму не имеет отношения к ООП, её гораздо удобнее делать на уровне модулей.

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

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

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

А что собственно мешает реализации ПП в С++-like ООП языках? Не троллинга ради, просто любопытно.

А что собственно мешает реализации ПП в С++-like ООП языках?

Да ничего не мешает. Собственно, дженерики C# уже получше джавовских, уже почти то, что надо.

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

кто-то запрещает сохранить ссылку на старую функцию и вызывать её если необходимо?

Да ничего не мешает.

Ну, если точнее, есть затрудняющий момент - ПП не очень хорошо сочетается с наследованием (если class D : public Base, то кто чей подкласс - T<D> подкласс T<B>, наоборот, или ни то, ни другое?) но эту проблему, можно считать, решили даже в жабе (T<? extends B>, T<? super D>).

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

ahonimous> первое это С с прибитым сбоку ООП, второе - целая платформа
make me unsee it

выколи себе глазки

> Сухой остаток. ООП представляет из себя еще один уровень абстракции

Нет, ООП это метод декомпозиции+метод организации кода, к абстракциям (которые могу быть, а могут и нет) отношения это не имеет.

Распространение ООП сильно приувеличено. Особенно ООП сложно реализовать в приложениях работающих с БД (оргнанизация логики крутится в основном вокруг выполнения транзакционных процедур), в распределенных приложениях (удаленный вызов _процедур_, будь он хоть rest, хоть что, все равно вокруг процедур крутится), сильно ограничено применение ООП в многотредовых приложениях. Были попытки возрождения труъ ООП в БД-ориентированных приложениях в виде так называемого Domain Driven Design. Погуглите на тему Distributed Domain Driven Design и поймете на сколько это все дохло.

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

На мой взгляд одним из важнейших плюсов ООП (причём в довольно широком понимании ООП) состоит в том что типы данных характеризуют не их физическую структуру, а семантику задачи. Соответственно, при правильным образом сформулированных типах данных, компилятор проверяет ещё и непротиворечивость семантики программы. Есть и минусы. Например C++-like ООП любит наслаждаться страдать от хрупкого базового класса. Ну и в широком спектре задач от базовго класса наследуется помимо интерфейса очень немного.

А вот DBIx::Class (http://search.cpan.org/dist/DBIx-Class/lib/DBIx/Class.pm) можно считать за «ООП подход» при работе с БД?

типы данных характеризуют не их физическую структуру, а семантику задачи.

Проржался.

То, что «типы данных характеризуют семантику задачи» - это признак не ООП, а хорошего программирования.

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

За ООП-подход при работе с бд можно считать смолтоковый GLORP

ООП - это испорченная вариация ФП. ФП - это испорченная вариация ООП. Ом мани падме хум.

/thread

А OCaml тогда что? Вдвойне испорченный язык?

За ООП-подход при работе с бд можно считать смолтоковый GLORP

Вполен. Только этот GLORP очень уж на жавский Hibernate похож...))

>В чем заключается революционность перехода от функциональщины к ООП?

Проектировать в терминах объектов проще

Язык, в котором можно выбирать метод извращения.

> чтобы не было путаницы с Ъ-функциональными языками - вы же имеете в виду как раз процедурные языки

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

А перл тогда как?

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

Товарисч, ты в своём уме?

Он извращение по определению, независимо от ФП и ООП:)

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

Товарисч, ты в своём уме?

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

Перл происходит от баша и авка как их улучшенная вариация.

Все очень просто.

Каждое нечто, что мы можем наблюдать в повседневной жизни (будь то человек, здание, дерево, карандаш, насекомое, автомобиль, и тд и тд) — имеет состояние, имеет составные части, является разновидностью чего-либо. То есть является объектом.

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

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

Ну а языки вроде C++ и Java позволяют с минимум трудозатрат воплотить результаты ОО анализа и проектирования в машинный код.

>>В чем заключается революционность перехода от функциональщины к ООП?

Проектировать в терминах объектов проще

Похоже всё упирается в термины, а термины это симптоматика конкретного случая ФГМ. Тоесть по распостранённости термина можно делать оценки о распостранённости конкретной вариации ФГМ.

Вот эти слова: «объект», «функция», «действие», «предикат»...

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

ручка.писать(текст, бумажка)
бумажка.написать(ручка, текст)
текст.написаться(ручка, бумажка)

>ручка.писать(текст, бумажка) бумажка.написать(ручка, текст) текст.написаться(ручка, бумажка)

Что-то очень знакомое... я кажись такое видел в Ruby.

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

А это именно то что надо промышленности, вот и все причины успеха.

Лучше говорить не «функциями», а «процедурами»/«подпрограммами» (чтобы не было путаницы с Ъ-функциональными языками - вы же имеете в виду как раз процедурные языки).

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

>а термины это симптоматика конкретного случая ФГМ.

Нет, я имел ввиду мнение, высказанное этим оратором, расписывать было лень:
http://www.linux.org.ru/forum/development/5034750?lastmod=1277284175772#comme...

Т.е. при использовании ООП мозг работает в нормальном привычном режиме, а всякая функциональщина как раз развивает ФГМ.

писатель.подготовить(бумажка)
писатель.подготовить(ручка)
писатель.писать(текст)

Если в голове каша, то лучше заняться чем-нибудь другим. Двор подмести, забор покрасить... У некоторых вообще iq=60, чем тут поможешь?

>Функциональный язык позволяет писать категориями функций (создавать и вызывать их), вот и всё. Про запрет императивщины, ленивость, вывод типов и отсутствие сайд-эффектов в определении ничего не сказано.

По такому определению можно и C назвать функциональным, ведь ссылки и указатели на функции можно передавать и возвращать...

> Де-факто мы генетически и значительной частью своего прижизненного опыта приспособлены воспринимать и мыслить в терминах объектов.

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

Но мне вот интересно --- является ли процесс (процесс в смысле эволюции объекта) объектом? Всегда ли можно использовать объектный подход при формализации различных понятий и категорий?