Thread by @mokevnin

Сегодня последний тред из мифов в ООП #oopmyths Поговорим о том, что обычно считают ООП кодом и что влияет на его структуру больше всего. Какие вещи в ООП универсальны сквозь большинство языков. Включайтесь)

Ну и традиционно вопрос. Может ли код быть одновременно объектно-ориентирован и функционален?

Несмотря на любую теорию, на практике, многие программисты если не видят в коде конструкций вида something.do(data), то они не считают код объектно ориентированным. Проверял это много раз. Все это сопровождается философией в стиле "это поведение", а иначе нет.

То есть код в стиле do(something, data) уже не поведение. Тут мне добавить особо нечего, это всего лишь варианты синтаксиса и привычка. Есть языки типа Nim, в котором используется Unified Function Call. Любую функцию можно вызывать аж тремя способами включая способ через точку

Но не каждый вызов функции равен вызову через точку. Нужно учитывать наличие динамической диспетчеризации (иногда говорят отправка сообщений). Если она есть при вызове функции, то мы получаем практически полный эквивалент. Хороший пример это полиморфизм в Elixir.

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

Если внимательно посмотреть на best practice, то можно заметить как много внимания уделяется компоновке классов и их связям между собой. Причем как горизонтально (использование друг друга) так и вертикально (наследование). Тот же SRP. Принцип возникший из ограничений классов

В итоге можно получить такую цепочку. Связали все вместе, получили свой набор ограничений, получили динамическую диспетчеризацию (метод выбирается в рантайме) и, в конечном итоге, получили свой очень узнаваемый стиль и целую индустрию вокруг с книгами, паттернами и языками

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

Создатель Erlang Joe Armstrong писал в своей статье cs.otago.ac.nz/staffpriv/ok/J…

> Data structure and functions should not be bound together

> Objects have private state.

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

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

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

Ну а что такое ООП, пусть каждый для себя решает сам)