Как я отмечал в [1]: “в ИТ-сообществе нет единого мнения о том, что такое ООП. Достаточно отметить, что ООП в Go и Rust принципиально отличается от ООП в C++ и Java…”

Если подняться выше над частными, воплощенными в разные языки программирования, взгляды на ООП, мы можем поставить перед собой вопрос: какие выразительные средства языков программирования можно считать объектно-ориентированными? 

Замечание: Более общий вопрос — а что же такое ООП я не буду рассматривать, так как меня интересуют ответы на практические вопросы. Хотя нам придется подумать об ответе на вопрос: зачем нам ООП?

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

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

Итак:

1. Мне нужно выбрать ОО средства для проектируемого языка программирования. И мне сильно бы помог результат сравнительного анализа или, хотя бы, список возможных средств.
2. Увы, я не знаю о существовании нужного мне списка, и тем более, анализа. Как это часто бывает — хочешь, чтобы было сделано хорошо, сделай сам. 

Это очень странно, но ООП — является скорее местом религиозных войн, чем темой научных исследований. С точки зрения науки, ООП — это слепое пятно, заполненное туманными словами типа “инкапсуляция, полиморфизм, наследование” или псевдо-философскими попытками рассказать нам о том, что ООП, каким-то волшебным образом, позволяет отразить реальный мир в виртуальном. И, видимо, есть еще злой волшебник, который этому препятствует…

Единственная работа, которая (вроде бы) может мне помочь, это A Theory of Objects by Martin Abadi and Luca Cardelli, впервые изданная в 1996 г. Обязательно попытаемся извлечь из неё пользу. 

Но до этого, надо определится еще с тем, почему я рассматриваю средства ОО, а не другой парадигмы, например, функционального программирования?

Дело в том, что ОО средства нужны на двух уровнях:

• нижнем (уровне синтезирующего программирования, см. [2])
• и на верхнем (уровне сборочного программирования), где ОО нужен для описания взаимодействия между компонентами.

Я много уже писал о том, что меня гораздо больше интересует разработка программ на верхнем уровне, а не программирование (кодирование), см., например, [3].

Замечание: Взаимодействие между компонентами не всегда выражается в ОО терминах. Очевидный пример — Unix pipe есть способ задания потокового взаимодействия между утилитами. То есть ОО взаимодействие необходимо, но недостаточно. С другой стороны, подключение/отключение потоков может быть выражено в ОО стиле, поэтому, с моей точки зрения, ОО взаимодействие является основным.

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

[1] OOP or not OOP or better OOP

[2] А.П. Ершов, Предварительные соображения о лексиконе программирования

[3] Программирование в малом и большом