Thread by @mokevnin

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

Отношение общее-частное это:

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

Под типами и подтипами часто понимаются интерфейсы (и их аналоги типа протоколов) и отношения между интерфейсами. Иногда говорят "наследование интерфейсов". Соответственно классы и наследование классов тут не причем. И принципов Лисков не имеет отношения к классам.

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

Пирс в своей книги ТАПЛ говорит примерно следующее: Вероятно, самая фундаментальная
характеристика объектно-ориентированного стиля – это то, что когда по отношению к объекту применяется некоторая операция, то
объект сам определяет, какой именно код будет её осуществлять.

Сразу обратите внимание на то, что он не утверждает "это главное", он делает предположение, именно потому что ооп в каждом конкретном языке это какая-то своя история и понимание (вспомните разные школы). Что он имеет ввиду? =>

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

Механизм диспетчеризации в разных языках разный. В большинстве языков это виртуальная таблица методов, которая живет в памяти работающего приложения. При вызове метода рантайм бегает по ней и ищет правильную функцию для вызова. Подробнее в вики: en.wikipedia.org/wiki/Dynamic_d…

В других языках, таких как self или js, диспетчеризация основана на линках между прототипами. Когда поиск идет по цепочке прототипов. Фактически именно механизм диспетчеризации делает возможным полиморфизм подтипов. Но здесь начинается темная сторона.

Очень много где, включая википедию, вызов метода называют передачей сообщения. Потому что действительно это не прямой вызов функции. Объект "сам решает" как ему поступить. Но это не имеет никакого отношения к тому что имел ввиду Алан Кей когда говорил про сообщения =>

В примерах выше выбор нужной функции происходит скрыто от пользователя, он не может на это повлиять. Если функции не оказалось, то возникнет исключение "метод не существует". То есть вроде как объект решает сам, но на самом деле только частично. Набор операций задается заранее.

Передача сообщений по Кею, подразумевает действительно полный контроль над обработкой "вызова" метода. То есть если метода не существует, то, обычно, вызывается какой-то специальный метод, который может обработать вообще любые вызовы.

В PHP это __call, в Ruby method_missing, в SmallTalk wiki.c2.com/?DoesNotUnders…, в javascript Proxy (с ограничениями и сложностями). В статических языках вроде c# может что-то, но про остальные не скажу.

Обязательно: wiki.c2.com/?MessagePassing

Дальше всех в этом отношении идет Erlang (Elixir) и другие языки с model actor. В этих языках посылка сообщения асинхронна и с легкостью может оказаться вызовом кода на другой машине (эрланг умеет в распределенный код из коробки). Эрланг это космос в плане реализации идей Кея.

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

Кроме всего прочего, сам процесс диспетчеризации, можно тоже представить себе как функцию, которая определяет, а что собственно выбрать. И вот здесь на сцену выходят лиспы с clos en.wikipedia.org/wiki/Common_Li…

Эта штука была изобретена в конце 70 под влиянием смолтолка. ООП в лиспах.

В отличии от привычного подхода где диспетчеризация базируется на классе/прототипе (single dispatch) и вшита в кишки рантайма, в CLOS функция диспетчеризации описывается программистом. Что открывает фантастические возможности по тому как выбирать подходящую функцию для вызова

Можно считать это следующей ступенькой после полиморфизма подтипов. Шире всего (я думаю) такой подход используется в Clojure (и есть в groovy и c#) en.wikipedia.org/wiki/Multiple_…

clojure.org/reference/mult…

Он позволяет реализовывать полиморфное поведение без генерации кучи классов

Кроме того, в CLOS данные и методы живут отдельно друг от друга. Но результат ровно такой же как и в привычном стиле "объект.метод()". Более того, если нам не нужна диспетчеризация, то ее и не нужно добавлять. Что делает код и проще и производительнее.

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

С другой стороны, в головах многих ООП это несколько другая история. И она сильно завязана на объединение данных и методов вместе. Вот это интересный момент, про который будет отдельный тред. На сегодня все. На следующей неделе разберем: наследование, инкапсуляцию, абстракцию.

Оу забыл. Большинство описываемых паттернов сводятся к применению полиморфизма подтипов в разных ситуациях: ru.hexlet.io/courses/js-pol…

адаптер, состояние, стратегия, nullObject, композит и другие

Ну и напоследок: ocaml.org/learn/tutorial…

OCaml is an object-oriented, imperative, functional programming language :-) It mixes all these paradigms and lets you use the most appropriate.

Между ООП и ФП нет никакого VS. VS есть между декларативным и императивным программированием