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

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

Печаль, печаль… Прочитал изрядную часть “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, но традиционные фреймворки несут на себе тяжелую печать классического ООП, а именно:

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

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

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