ООП умирает

К такому выводу я пришел.

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

Я просто акцентирую внимание на трендах.

Существует тренд веб-программирования. Он основан на упрощенной модели
объекта. Объекта прототипа. Лишенного каких либо строгих правили проектирования.
ПО сути веб-программист оперирует микро-хеш-тебличками в узлах которых
лежат произвольные безтиповые сущности. Могут быть полем. Либо функцией (методом).
Веб программирование - многолико. Оно не обязательно основано на JavaScript.
И оно не обязательно стоит в стеке браузера. Часть его - охватывает бэк-енд.
С теми-же либеральными правилами.

Существует тренд декларативного программирования на аннотациях (как один
из способов взаимодействия с АОП). Аннотации полностью разрушают идеологию ООП.
Они игнорируют (или обладают такой способностью) языковые иерархии классов.
Они способны полностью поменять семантику зависимостей между классами. Они
способны внедрить невидимый интерфейс. Создать невидимый прокси. Добавит
логгинги, транзакции и политики безопасности. И все это - перпендикулярно ООП.
Тоесть вне закона ООП. Этот тренд поддерживают современные Java/C# в виде
синтаксиса и фреймворков.

Существует давление т.н. функционального программирования. Интерес к нему
периодически то понимается то спадает каждые 5-7 лет. Но совершенно очевидно
что растущие ресурсы датацентров создают условия для того чтобы запускать
в проуктив смелые и экспериментальные проекты на которые раньше все время
чего-то не хватало. Сегодня - оптимизация for/while циклов чтобы добыть лишние
несколько тактов CPU перестала быть актуальной. Скорость внедрения решения
в прод. - для бизнеса важнее. Сюда-же до кучи Spark/BigData - как одну из имплементаций.
Компилляторы стали умнее. Стали видеть намного уровней дальше. И человек (программист)
как винтик этой системы в части оптимизации - выпал. Он - не нужен. Пускай он лучше
думает над логикой верхнего уровня. We trust in compiller, bro!

Существуют языки-отступники. В которые заложена дерзкая идея - отменить некоторые
законы ООП которые вообще были раньше незыблемы. Например - утиная типизация в GoLang.
Это - вызов. Это - перчатка в лицо класиическим ООП языкам.

Существует интерес к т.н. акторному программированию (Erlang/Sony-Ericson как один
из примеров имплементации). Полностью лишая логику состояния - он постулирует
чистый рафинированный мир тестабельных компонент. Есть месседжи. И есть компоненты
акторы. Эдакий себе Rest в пределах кристалла процессора. В довершение ко всему
акторное программирование выводит новый уровень "отказоустойчивости" из коробки.
Как вам? Потрясающе! И где здесь ООП? Месседжи? Ничего подобного. Это POJO. Или
Records(Pascal). Или Tuples. Никакой инкапсуляции. Акторы? Возможно. Но с натяжкой.
Ибо мало мотиваций. Для системы в которой единицей информации являются Tuples.

Существует интерес к тестированию на Mocks(Mokito). Которое "срезает кожу" с ООП.
Оно "ломает" правила private. Шпионит за методами. Вобщем полный набор мозговых
извращений.

Это тоже бъет по лицу ООП.

ООП - корчится. Ему нечего сказать в ответ. Оно - осталось в пыльных библиотеках
университета в виде толстых и умных книжек года эдак 2000-го про системный анализ или может
быть про ООП в С++. Или в старых изданиях Java.

Оно еще осталось в виде дурацких вопросах на собеседовании. Где тех-лид с умным видом
может вас спросить про "ромбовидное наследование" или про матрицу видимости public/protected/private.
Это ... если захочет вас окончательно макнуть в грязь...

Но я надеюсь что таких тех-лидов мы будем видеть все меньше и меньше.

Вот как-то так.

Спасибо всем кто дочитал мои буквы. Рад буду услышать ваши каменты. Поздавляю вас с Пятницей.

Ваш покорный слуга
mayton

mayton
Но я надеюсь что таких тех-лидов мы будем видеть все меньше и меньше.

Надеюсь, этот очередной абсолютно бестолковый крестово-похоронный демарш, объясняется пятницей

mayton,

Попробуй взглянуть на тему с другого угла:
Как раз утиная типизация и поведение, выражаемое в "акторских" терминах - характерные признаки "объектной ориентированности".
Там где это нет, или даже не может быть - происходит неправомерный захват и использование терминов.

По мысли изобретателей самого термина оно скорее еще не состоялось, чем умерло.
Если и умерло - то в части попыток описать сложный мир взаимодействующих объектов
прокрустовыми описаниями мира жизни программ наборами фиксированных иерархий классов.
Живой мир программирования никогда не ложился и никогда не ляжет в те ложа. Тут не надо быть Тэсеем.
Достаточно поговорить с театральным дизайнером, классическим органистом и джаз-гитаристом Аланом Кертисом Кэем (Alan Curtis Kay).

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

И, полагаю, вряд ли можно добиться того чтобы, например, Страуструп с энтузиазмом рассказывал о С++
именно как о языке "объектного программирования" с целью пропаганды последнего.

Дополню про Функциональное программирование. Некоторые считают что его нет.
Что это метафора. Я зайду с другой стороны. Никакого ООП нет. Процитирую слова моего хорошего приятеля.
Инструктора по Scala/Haskell.

- Никакого ООП не существует. ООП - это миф. Это обычное процедурное программирование
где каждый метод имеет неявный аргумент this.

Добавлю про Наследование. Inheritance. Справочник переводит это термин как наследоство, унаследованное,
наследование. Что тут сказать?

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

По поводу многоуровневого наследования. У меня есть личная неприязнь к подобного рода проектированию.
Это - хуже чем goto. Особенно когда отладчик перемещает вас вверх-вниз по иерархии. Честное слово! Лучше
композиция. Руки хочется поотбивать таким горе-кодерам.

Добавлю своё собственное утверждение которе я писал давно в форуме.

- Не существует никакого математического доказательства пользы от внедрения ООП.
Есть просто наша вера в то что ООП - это хорошо. Мы никогда не сравнивали два проекта ООП-не-ООП.
Никогда не меряли velocity Scrum-команд работающих в одинаковых условиях с ООП и не ООП.

Добавлю цитату одного из мемберов по поводу множественного наследования.

- Множественное наследование - это "бантик сбоку".

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

hVostt
mayton Но я надеюсь что таких тех-лидов мы будем видеть все меньше и меньше. Надеюсь, этот очередной абсолютно бестолковый крестово-похоронный демарш, объясняется пятницей

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

P.S. Какие ваши доказательства? (с)

booby
mayton, Попробуй взглянуть на тему с другого угла: Как раз утиная типизация и поведение, выражаемое в "акторских" терминах - характерные признаки "объектной ориентированности". Там где это нет, или даже не может быть - происходит неправомерный захват и использование терминов.

Я-бы не стал проводить параллели между "акторским" ООП и нашим ООП. На заре строительства Erlang (1992)
наш ООП также развивался поэтому у каждой архитектуры было свое определение ООП.

По поводу уток. Меня часто раздражала ситуация когда при внесении изменений в базовый интерфейс - тонна
кода становилась шлаком. Но еще более настораживает "молчаливое согласие" утенка-компиллятора
взять и собрать просто "похожий" по методам код. Есть в этом что-то коварное... Знаете. Как затишье
перед бурей.

booby
Если и умерло - то в части попыток описать сложный мир взаимодействующих объектов прокрустовыми описаниями мира жизни программ наборами фиксированных иерархий классов. Живой мир программирования никогда не ложился и никогда не ляжет в те ложа. Тут не надо быть Тэсеем. Достаточно поговорить с театральным дизайнером, классическим органистом и джаз-гитаристом Аланом Кертисом Кэем (Alan Curtis Kay).

Вот с этого момента не понятно. С каким-каким описанием мира? Какой Тесей? Этот тот который в лабиринт ходил?

P.S. Не знал что Алан Кей - дизайнер и музыкант.

booby
И это, если у тебя есть средства отладки, позволяющие подсмотреть, что там происходит с объектами и в каком порядке - то ты, наверняка, имеешь дело не с объектным программированием. Оно, в варианте какого-нибудь smalltalk, отладке в обычном смысле почти не поддается, поскольку не подлежит.

Хм.. не знал что в smalltalk есть проблемы с отладчиком. Это... принципиально неустранимо? Или были
идеологические причины?

И, полагаю, вряд ли можно добиться того чтобы, например, Страуструп с энтузиазмом рассказывал о С++ именно как о языке "объектного программирования" с целью пропаганды последнего.

Я давно ничего не ожидаю от старины Бьярне. Его модель ООП не намного лучше или хуже чем Java/C#.
Но еще до того как заниматься языко-строительством старику надо было пофиксить старые болячки
языка. А именно - ввести нормальный тип даных int, long с сеткой соответствующей хотя-бы одной спеке.
И ввести нормальный атомарный строковый тип. Можно даже мутабельный.

Господи-боже. Неужели это было невозможно?

mayton
К такому выводу я пришел.....

Ну пришел, хорошо, что дальше.

Так давай выкинем ООП (в твоей, старой, узкой интерпретации) из Явы, или из Явскрипта, или из ОС. Представил, что останется?

Гвозди тоже устарели. Суперклей же есть, и шурупы...

Да и буквы, в общем, тоже.

Согласен. Но нужно ввести понятие Tuple, и функции все скоупа класса. Просто функции.