Отказ от Объектно ориентированного программирования

Наследование

Наследование предполагает что мы имеем набор классов выстроенных в строгую иерархию. Каждый потомок наследует интерфейс и реализацию класса предка.

Множественное наследование

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

Наследование "Интерфейс" vs "Реализация"

Так что же мы наследуем, интерфейс или реализацию? Обычно наследование в ООП языках смешивает в единое неразрывное целое наследование реализации и наследование интерфейса. Что есть суть различные процессы. А что надо наследовать?

Нас убеждают что наследовать интерфейс это хорошо. И можно даже согласится что наследование интерфейса дает нам богатые возможности для полиморфизма. Нас убеждают что наследовать реализацию это хорошо. И этим тоже сложно поспорить - повторное использование оттестированного кода кажется не может быть плохим решением. Но программисты вынуждены наследовать всё скопом. И если возникает необходимость наследовать что то одно приходится идти на сделку с совестью и реализовывать часть задачи некоторым костылем.

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

С наследованием реализации хорошо справляется шаблон "делегирование". И о ужас! Знаменитая банда, пророки ООП, в описании этого шаблона, предлагает отказаться от наследования реализации и, по возможности, заменять её на делегирование и композицию.

Исходя из вышеизложенного можно прийти к выводу что достаточно наследовать интерфейс, и все классы кроме целевого и его примесей и аспектов не должны содержать ничего кроме описания интерфейса. Тогда встает вопрос - зачем для этого использовать классы? В любом случае большую часть их нагрузки мы не можем использовать, но вынуждены с трепетом относится к их ограничениям.

Наследование

Инкапсуляция

Инкапсуляция и повторное использование кода

Маркетологами, объектно ориентированных языков программирования, прочно внедрен в наше сознание миф о том что ООП облегчает повторное использование кода. И многие программисты, поверив в этот миф, часами всматриваются в иерархию классов в надежде получить прозрение и повторно использовать код каким либо методом, отличным от копирования и вставки. Некоторые разработчики языков программирования, осознавая масштаб проблемы инкапсуляции, отказались от нее. Например в языке Python все методы публичны и их использование остается на совести программиста.

Код инкапсулированый в protected секции можно использовать исключительно породив наследника. В результате чего появляются страшные монстры - киты наследованные от автомобилей только по той причине что в классе автомобилей удачно реализован код перемещения объекта по карте. Я промолчу о коде погребенном в private и strict private секциях. Выглядит так что ООП активно сопротивляется повторному использованию кода.

Хрустальный шар

Инкапсуляция и пророчества

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

Полиморфизм

Полиморфизм возможность объектов с одинаковой спецификацией иметь различную реализацию. Это то что можно назвать лучшей идеей которую привнесла нам идеология объектно ориентированного программирования. Полиморфизм на самом деле позволяет повторно использовать код и выражать программы более лаконично.

Что делать?

В целом мы разобрались с тем кто виноват, Теперь необходимо выяснить - что делать? Как сохранить то лучшее что привнесла нам парадигма Объектно ориентированного программирования. И избавиться от её пороков? В этой статье я кратко сформулирую основные принципы предлагаемого подхода. Более подробно каждый пункт будет рассмотрен в отдельных статьях.

Интерфейсы

Для сохранения всех достоинств полиморфизма необходимо сосредоточится на интерфейсах как на наиболее абстрактном способе описания сущностей. В идеале надо отказаться от какого то бы ни было их наследования. Каждый интерфейс должен являться законченным описанием свойств и методов для потребителя. При этом конкретный интерфейс должен быть сосредоточен на решении узкой задачи. Интерфейсы-комбайны умеющие делать всё подряд недопустимы при правильном проектировании поддерживаемого кода.

Типы

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

Классы

Классы являются контейнерами реализации. Не наследуются друг от друга. Но могут заявлять о реализации ряда интерфейсов. Важно обратить внимание на то что классы не реализуют типы и не являются ими. Реализацию части своих интерфейсов класс может делегировать вложенным в него объектам.

Параметризация

Максимально абстрагироваться можно только имея мощный механизм параметризации интерфейсов, типов и классов. Язык программирования Денеб позволяет максимально свободно пользоваться параметризацией сущностей.

Комментарии

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

Старый домен уже не работает. Будет ли выложен архив и желательно последняя работающая версия сборщика? Я ждал исправления багов, а в итоге всё вообще пропало. Не красиво так поступать с энтузиастами языка. Судя по посещаемости сайта их не так уж и много. Можете последних растерять.

Кстати форма коментариев глючит - расползлась по разным частям экрана. И установите какой нибудь форум. Неудобно писать под статьями.

Старые программы вполне будут собираться если сохранились все .nuss и .xslt файлы. Я стараюсь сохранить совместимость. Да - новый сборщик ещё не дописан и не работает. Я активно работаю над ним. И приглашаю желающих присоединиться к этой работе. Архивы выкладываться не будут это не имеет особого смысла - старый код поддерживаться больше не будет. У новой реинкарнации будет намного больше возможностей и она будет совместима со старыми. В частности интерфейсы, типы и классы войдут в стандартную библиотеку языка. Ранние .xslt для классов будут работать, но использовать их не рекомендуется. Напишите мне на почту я вам вышлю архив. Или зарегистрируйтесь на новом сайте выложу в личку. Энтузиасты есть. Просто в связи с долгим бездействием на сайт никто не заглядывает. Собственно решение о переписывании было принято в результате совместных консультаций.

Форму комментариев поправлю, форум прикручу.

Слабое утешение!