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

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

Это ты чуть позже опровергнешь.

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

Да потому и не запретили, потому что сообщение это передача данных.

A>Еще была фантазия о том, что нам легче понимать ООП код, так как мы якобы сами мыслим мир как совокупность объектов с поведением.

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


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

И это тоже сейчас опровергнешь.

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

Вот и опровержение.

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

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

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

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

A>Практика показала, что она отличается от теории и стало понятно, что повторная испольуемось достигается за как раз счет полиморфизма, а не наследования. Появились Coding to the interface, GoF и т.п.

Повторное использование это гораздо шире, чем наследование или полиморфизм или инкапсуляция или всё вместе.

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

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

Абстракция давно уже четвертый кит.
Взаимодействие — еще один.
Поведение — еще один.
Вместо "данные + методы" используем подход "сервис который занят обработкой данных", типа "экскаватор копает землю" @ Sinclair

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

А тут надо вспомнить Алана Кея и его принципы. Эта ветвь ислама ООП никогда не переставала быть актуальной. Самое главное в ООП — это обмен сообщениями, абстрагирование, иерархическая композиция объектов, взаимодействие, моделирование поведения.

Например, нет поведения — надо еще поискать. ради чего ооп-шить.