Как выбрать ОО средства для языка программирования?

таблица ООП

Как я отмечал в [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] Программирование в малом и большом

3 комментария


  1. Действительно, понятие трубы в Юниксах достаточно продуктивно. Фактически в Go — через конкурентные потоки описываются этакие минитрубы. Этого механизма не хватает в Компонентном Паскале (на сколько понимаю, нечто подобное сделано в в работе орловской команды), в форме библиотеки (отдельно, а не с переделкой ядра) вроде такого нет.
    В Go не выполнено в полном смысле CSP, но тем не менее вполне понимаю, почему авторы пошли именно таким путём — оставили пространство для манёвра тем, кто на практике использует Go (повышение эффективности за счёт некоторого снижения надёжности — ничего нового).
    Что касается самого ООП в выражении С++ — это исчадие преисподней. Нет, нет — это в другую дверь))

    Ответить

  2. Скорее всего для вас это не новость, но на всякий случай скажу.

    У Л.Кардели на его сайте в разделе «Past» кроме ссылок на книгу есть и старые статьи на тему ООП, в том числе и «Bad Engineering Properties of Object-Oriented Languages»

    Ответить

    1. Спасибо. А писал ли он там что-нибудь такое, что не писали другие? Какое-то время назад я много читал подобного, но наскучило. Время собирать камни…

      Ответить

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *