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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Полиморфизм

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

Что делать?

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

Интерфейсы

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

Типы

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

Классы

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

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

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