Что может дать нам ООП?

Всё ОО казалось дивным
Триста Двадцать лет тому назад!

           Черепаха Тортила

Печаль, печаль… Прочитал изрядную часть “A Theory of Objects” и не нашел ничего полезного для себя. Сомнения, впрочем, были изначально, слишком уж давно написана книга (первое издание — 1996 г.).

В 1996 году у меня еще оставались некоторые иллюзии по поводу классического ОО, не очень много, так как к тому времени я написал ОО среду Mithril (кандидатская диссертация защищена в 1994 г.). В начале работы над Мифрилом я был большим оптимистом, тщательно изучал Oberon System и думал, что я могу сделать лучше. Тогда я уже увидел, пусть не так явственно, как сейчас, что классический OOP (CLOP) приводит к жестким (негибким) конструкциям, и чем дальше, тем хуже. Ситуация с Обероном чуть лучше, все же Оберон позволяет писать немного гибче. Но этого совсем не достаточно для обеспечения хорошего уровня переиспользования: чем дальше в лес (глубже иерархия классов), тем жестче дрова (классы). 

Тогда же, в 1994 году я выступил на конференции JMLC’94 (Joint Modular Language Conference) с докладом “Restricted Multiple Inheritance”, где предлагал добавить нечто вроде того, что сейчас называется интерфейсами, в Оберон и описывал эффективную реализацию. 

Видимо у авторов книги “дивность” начала спадать с ОО позже. Впрочем, думаю, что выйти из под «очарованностиЭ ООП достаточно сложно, все же мой опыт достаточно необычный. Проектирование системы классов с нуля, а это то, что я проделал, работая над Мифрилом, дает существенно более богатый опыт, чем любое другое использование ООП.

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

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

На мой взгляд, единственной полезной отправной точкой является использование.

Посмотрим с этой точки зрения: что может дать ООП?

  • набор полезных “классов” (контейнеры и прочее)
  • возможность создания удобных типовых систем для приложений (например, компилятора)
  • определение абстрактных интерфейсов (Go interface, Rust trait, Swift protocol)
  • удобный интерфейс с библиотеками (движками, …)
  • определение интерфейса взаимодействия компонент, в том числе и распределенного взаимодействия

Кажется это все. Можно добавить еще ОО frameworks, но традиционные фреймворки несут на себе тяжелую печать классического ООП, а именно:

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

Так что их я сейчас не рассматриваю

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

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


  1. Давно понятно, что ООП в классическом виде — это ошибочный путь. Вирт прошёлся катком ещё очень давно, и чем дальше в лес — тем толще партизаны (это очевидно).
    Что касается связности, переносимости, достаточной гибкости — прям про Компонентный Паскаль статья))
    В любом случае, Ваш творческий подход интересен именно тем, что выполняете все работы самостоятельно и с нуля. не быстро, но действительно ценно.

    Ответить

  2. >Посмотрим с этой точки зрения: что может дать ООП?
    >набор полезных “классов” (контейнеры и прочее)
    >возможность создания удобных типовых систем для приложений (например, компилятора)
    >определение абстрактных интерфейсов (Go interface, Rust trait, Swift protocol)
    >удобный интерфейс с библиотеками (движками, …)
    >определение интерфейса взаимодействия компонент, в том числе и распределенного взаимодействия

    В этом списке вообще нет ничего характерного именно для ООП, всё это легко может дать и современное ФП, а точнее — современные системы типов, благодаря которым можно создать наборы всех этих стандартных контейнеров и прочего,
    системы типов для тех же компиляторов просто идеально ложатся на ФП,
    интерфейсы-трейты — это упрощённые классы типов из того же хаскелла,
    FFI так же не имеют принципиальной привязки к ООП,
    протоколы взаимодействия объектов можно описать сессионными типами…
    В общем, всё это можно указать и как достоинства ФП…

    Ответить

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

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