|
© 2025
Александр Легалов
Содержание
Что в итоге?
Является ли объектно-ориентированное программирование, отстоем? Я не говорил этого раньше и не скажу так сейчас. Есть ряд направлений развития ООП, которые интересны и возможно перспективны. Но то, что взгляды на его использование в качестве всеохватывающего универсального средства стоит пересмотреть, мне кажется вполне логичным.
Реализация ОО паттернов, использующих динамический полиморфизм, показывает, что основная идея, связанная с выделением интерфейсов, базируется на попытке обойти простое решение, связанное с идентификацией признаков альтернативных конструкций.
Как реализовать признаки?
То есть того, что в традиционном процедурном подходе не обеспечивает необходимую гибкость. Однако использование процедурно-параметрической парадигмы решает практически большинство проблем, обеспечивая поддержку гибкой разработки программ без изменения ранее написанного кода. Помимо этого не нужно заморачиваться с первоначальным тщательным планирование содержания интерфейсов, боясь того, что в ходе добавления новых методов придется модифицировать значительную часть написанной программы. Вместо этого в любой момент можно сформировать нужный пакет из прототипов независимо разработанных функций и передавать его в качестве интерфейса нужным клиентам.
Непосредственная и эволюционная поддержка множественного полиморфизма в ПП подходе, также обеспечивает более высокую гибкость по сравнению с ОО полиморфизмом, при котором мультиметоды приходится реализовывать, используя диспетчеризацию. В результате этого многие прямые решения превращаются в вызов последовательной цепочки промежуточных методов, не несущих смысловой роли, а лишь поддерживающих конструктив, ограниченный техническими решениями, предлагаемыми через виртуализацию.
Акцентируясь в данной ситуации на ПП парадигме программирования, я не ратую за полную замену на нее везде и повсеместно. Ее "чистое" использование для имитации паттернов проектирования в данном случае ориентировано только для демонстрации возможностей продхода. Предлагаемые расширения C также реализованы только для демонстрации возможностей создания "чистого процедурно-параметрическго кода" путем внесения в язык минимальных расширений.
Я вполне допускаю, что разрабатываемые с нуля новые языки программирования могут формировать конструктивы программы с использованием сочетаний разнообразных подходов. Это могут быть и чистые процедурно-параметрические языки. Однако ничто не мешает добавить внутрь структур дополнительные методы, играющие вспомогательную роль и обеспечивающие прямое обращение к данным. Хотя я бы предпочел не делать их виртуальными. Также не вижу особых препятствий в использовании наследования в качестве расширения типов по аналогии с тем, как это реализовал Н. Вирт [Wirth2010Вирт Никлаус. Построение компиляторов, Москва, ДМК Пресс, 2010, ISBN 978-5-94074-585-3, Wirth1982Wirth, N. Programming in Oberon. A derivative of Programming in Modula-2 (1982)] в языке программирования Оберон. Над всем этим сверху можно спокойно подставить механизм, обеспечивающий поддержку процедурно-параметрического полиморфизма. И неважно, будет такой язык императивным или функциональным, с поддержкой метапрограммирования или без. Также неважно, каким способом будет или не будет реализована в нем поддержка параллелизма.
Познакомившись с ОО паттернами проектирования в 1998 году, я уже сбился со счета, сколько раз перечитал книгу Э. Гаммы и компании [gof-patternsГамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. Паттерны объектно-ориентированного проектирования. - СПб.: Питер, 2020. - 448 с.]. Изначально это было связано с попыткой понять их смысл. Затем были проекты с их использованием. Далее погружение в материал было связано с анализом альтернативных кодовых решений, предлагаемых процедурно-параметрической парадигмой программирования.
Определенные ретроградные мысли по поводу этих решений возникали и в целом о процессе разработки программного обеспечения. Если посмотреть на процесс проектирования ПО, то создается ощущение, что, вместо преодоления семантического разрыва [Legalov-2018Легалов А.И. О разработке программного обеспечения. Модельный взгляд. - 2018.], паттерны увеличивают его за счет замены прямых решений на дополнительные танцы с бубнами. Требуется выискивать нужные паттерны далеко не из 23 базовых предложений. Нужно заниматься тщательной проработкой интерфейсов. Их отсутствие при использовании ПП подхода тоже можно не заметить, предоставив для экспорта из модулей только тех функций, которые необходимы клиентам. Понятно, что это обусловлено стремлением к достижению определенных критериев качества. Но также связано, на мой взгляд, и с попытками сделать из ОО проектирования и программирования универсальную панацею от всех бед, отменяющую другие подходы. Анализируя простые решения, получаемые при имитации ОО паттернов, создается ощущение, что многие проблемы на этапах анализа и проектирования можно решить и без них, если на определенных этапах заменит ОО подход к разработке ПО на уже подзабытое структурное проектирование, но с использованием 4П.
Хочу также отметить, что я не противник паттернов вообще. Они весьма полезны в различных контекстах: от архитектурных и системных решений, и до уровня кодирования. Пусть их будет много разных и красивых, включая и объектно-ориентированные. Основная идея, которую хотелось бы донести, заключается в том, что универсальных подходов к разработке ПО не существует. Но есть варианты которые в определенных ситуациях могут оказаться эффективнее в лечении там, где делается попытка применить панацею от всех болезней, каковой до сих пор пытаются представить ООП.
Я думаю, что есть куда развиваться. Есть свои определенные планы. Они не охватывают всех возможных направлений, связанных с развитием новых языков программирования и методологических концепций. Но вряд ли все эти варианты можно реализовать в одиночку и выбрать из них оптимальное мультипарадигменное решение ("Нельзя объять необъятное"). Дерзайте, если есть вера в светлое будущее ППП и желание попробовать...
Содержание
|