Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, artelk, Вы писали:

A>>ООП родился как аналогия со ментальной моделью биологических организмов, состоящих из клеток. Поведение организма сложно, а клетки, из которых он состроит, якобы просты.
I>Это ты чуть позже опровергнешь.
Что именно?

A>>Клетки общаются сигналами без передачи вещества. Аналогом этому был data hiding с "посылкой сообщений" вместо передачи данных (неясно только почему параметры у методов при этом не запретили).
I>Да потому и не запретили, потому что сообщение это передача данных.
Значит мы на первом же шаге отходим от своей же аналогии, окей.

A>>Еще была фантазия о том, что нам легче понимать ООП код, так как мы якобы сами мыслим мир как совокупность объектов с поведением.
I>Именно. Один из подходов к проектированию в ООП, это представить, как бы эту задачу решала группа людей. Распределить обязанности, что бы не было конфликтов, выделить роли, выявить сущности, наладить взаимодействие.
Трудно придумать когда это может понадобится, кроме как собственно при моделировании поведения людей. Даже при моделировании ролей в бизнесс процессах нет смысла отвлекаться на то, что без компьютеров их бы выполняли люди.

A>>Не знаю как у других, но для меня объектами с собственным поведением мыслятся в основном только люди (ну и животные отчасти) и имено они являются самыми сложными штуками.
I>И это тоже сейчас опровергнешь.
Тут "в основном" всмысле "чаще всего", "бОльшую часть времени".

A>>Все остальное это пассивные предметы, состояние которых я могу менять: надавил на дверь — она открылась; нажал на педаль газа автомобиля — поехали.
A>>Автомобиль как нечто имеющее собственное поведение представлялся только в начале обучения езды на нем.
I>Вот и опровержение.
Не понимаю, что я опровергнул.
Объектом с собственным поведением воспринимается объект, поведение которого сложно и не предсказуемо.
Довольно странно при разработке приложения следовать этой метафоре и ожидать, что в результате поведение этого приложения не будет тоже сложным и не предсказуемым.

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

I>Проблема именно в трех китах и неправильном реюзе. Наследование плохо не потому, что реализация наследуется.
I>Наследование это 2 вещи
I>1. уточнение типа
I>2. расширение модуля

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

I>Более того, наследование итерфейсов никак не ухудшает ОО-ность. Тут ровно те же правила.
I>Если начнешь расширять интерфейс как модуль, появляются те же грабли, только в профиль.
Имхо, было бы полезно, если IList наследовался от IReadOnlyList. Это было бы уточнение типа или расширение модуля?
I>Если использовать интерфейс как уточнение типа — снова всё в порядке.
Примеров бы.

Джаву в 90х дизайнили очень ОО-нутые люди. Для указания наследования классов они выбрали слово "extends", что как бы намекает.
Не кажется ли тебе, что то, что ты считаешь современным ООП существенно противоположно тому, чем оно было в 90е?

А может то, что ты считаешь современным ООП, вовсе не ООП уже, а само ООП не сильно-то поменялось с 90х?

https://en.wikipedia.org/wiki/Object-oriented_programming
Думаю, что после полувека активного продвижения ООП в массы, в википедии, наверно, отражены наиболее распространенное мнение относительно того, в чем его суть.
А поскольку ООП это не то, что мы исследуем, а то, что постулируем (см. выше), то наиболее распространенное мнение и выражает содержание.
И "современное ООП" должно логически из него выводится и нисколько ему не противоречить.
Есть возражения?

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

A>>Практика показала, что она отличается от теории и стало понятно, что повторная испольуемось достигается за как раз счет полиморфизма, а не наследования. Появились Coding to the interface, GoF и т.п.
I>Повторное использование это гораздо шире, чем наследование или полиморфизм или инкапсуляция или всё вместе.
Да, Math.Abs можно использовать много где и никакого полиморфизма при этом не требуется. Но Math.Abs он и в функциональном и в структорном программировании такой же.
А мы тут обсуждаем что именно есть такого в ООП для обеспечения повторного использования.

I>Симуловскиая модель трех китов давно уже неадекватная. Но ООП не сводится к симуловской модели трех китов.

I>>>Софтварные продукты постоянно растут в сложности, а потому арсенал пополняется самыми разными приемами.
A>>Можно развернуто, с примерами?

I>Абстракция давно уже четвертый кит.
Ага, с какого-то момента стало модно к трем китам добавлять еще эту селедку.
Только зачем отдельным пунктом добавлять то, что подразумевается по умолчанию при обсуждении процесса разработки приложений безотносительно используемой парадигмы?

I>Взаимодействие — еще один.
I>Поведение — еще один.
Все эти слова, абстракция, взаимодействие, поведение, часто употреблялись в литературе 90х при описании того, что такое ООП; т.е. ничего нового.
Или у этих слов внезапно тоже появился новый, современный смысл?

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

I>>>А местные ОО-хейтеры до сих пор три кита ищут.
A>>Ок, три кита уплыли. Что осталось?

I>А тут надо вспомнить Алана Кея и его принципы. Эта ветвь ислама ООП никогда не переставала быть актуальной.
А не он ли сам утверждал, что все его неправильно поняли и он имел ввиду совсем другое, не имеющее ничего общего с тем, что получило распространение как ООП?
Тут три варианта что делать:
1. Поменять название у парадигмы, которая всеми ошибочно называется ООП, на какое-то другое, так как это название Алан Кей придумал для другого.
2. Решить, что этимология термина не всегда отражает его смысл и оставить название ООП этой парадигме. А для идей Алана Кея придумать новое название Message Oriented Programming.
3. Научиться вовремя отключать мозг, не замечать ничего странного.
Первый вериант невозможен по историческим причинам. Второй вариант не реализуется по причине того, что пока в массах побеждает третий.

I>Самое главное в ООП — это обмен сообщениями, абстрагирование, иерархическая композиция объектов, взаимодействие, моделирование поведения.
"Обмен сообщениями" требует уточнения. Без уточнения даже каждая строчка ассемблерного кода может интерпретироваться как некая "посылка сообщения от одного объекта другому".
Сообщения должны слаться асинхронно по принципу fire and forget?
Или это про то, что можно вызвать у объекта неизвестный на этапе написания программы метод, а объект в рантайме как-то разберется как его выполнять (т.е. сугубая динамика)?

Кстати, отсюда:

OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things.

"Еxtreme late-binding of all things" не подразумевает ли динамику всегда и во всем?