Статья на тему: «Компонентно-ориентированное программирование и его отличительные особенности»

Компонентно-ориентированное программирование

Эта парадигма программирования направлена прежде всего на повышение надёжности коммерческих бизнес-систем.

Суть компонентно-ориентированного программирования (далее КОП) сводится к возможности контролировать взаимодействие проектируемых и выполняемых модулей на предмет согласованности информационных структур. Идея является относительно новой. Частично идеи КОП воплощены в такие языки как Java, Ada, C#, прямым применением идей КОП являются языки программирования Modula-2, Oberon, Oberon-2, и наиболее известный из семейства КОП — Компонентный Паскаль.

Отличительные черты КОП

Не смотря на свою относительную молодость — КОП имеет свои особенности, которые регулируют не только особенности языка, но и всей экосистемы КОП.

К таким отличительным чертам следует отнести:

• Чётко выраженную ориентированность на модули. Модуль, является основной структурной единицей.

• Раздельная компиляция модулей. Это приводит к сбережению вычислительных и временных ресурсов.

• Строгая типизация, как внутри модуля, так и между модулями. Обеспечивает надёжную работу компонентов в целом.

• Неизбежность динамической сборки мусора. Для компилируемых языков это важный и необычный механизм.

• Строгое разделение частей модулей, предназначенных для взаимодействия с другими модулями, и скрытые части только для работы внутри модуля.

Отличия от функционального программирования

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

Ряд средств в функциональном программировании на самом деле избыточен, но другая часть действительно нужна, но это только усугубляет проблему: из-за различных эффектов характерных для функционального программирования, программисту легко потерять логику рассуждений и совершить какую-нибудь досадную ошибку, на выявление которой может уйти огромная часть времени. Такой язык, как Си — вполне выражает такую парадигму. Мощный, как трёхлинейная винтовка, и такой же опасный — можно шутя выстрелить себе в ногу с более чем фатальными последствиями. В целом, про функциональное программирование можно сказать, что оно отлично применимо к несложным проектам, которые должны работать с высочайшей скоростью на относительно простых аппаратных платформах.

Компонент-ориентирование программирование стремится всеми доступными средствами к надёжности и гибкости на сколько это возможно. В целом, программа представляет собой на КОП несколько хорошо изолированных частей. Это приводит к ясной структуре и простым эффективным правилам передачи и обработки информации, что безусловно положительно влияет на надёжность в целом. Сокрытие информации отсеивает лишнюю информацию для программиста, что позволяет ему сконцентрироваться на существенной части задачи. Упрощение языка и отказ от многих сомнительных приёмов программирования вынуждают программиста писать простой для понимания программный код, в котором трудно совершить досадную ошибку. Компилятор языка программирования в духе КОП не позволит создать программу, в которой программистом допускает нарушение отношений типов данных. Можно сказать, что требование к надёжности программ, создаваемых с помощью КОП является главным. В связи с этим, синтаксис языков специально спроектированных для компонент-ориентированного программирования достаточно прост и выразителен. Едва ли возможна, например, в таком языке как Компонентный Паскаль нечитаемая конструкция, как в уже вышеупомянутом Си. В попытках понять что имел в виду программист на Си можно провести огромную часть рабочего времени. В целом про КОП можно сказать, что он предназначен для крупных программных систем, к которым предъявляются особые требования к надёжности.

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

С точки зрения программиста, придерживающегося компонент-ориентированного программирования далеко не всё является объектом. Строго говоря, это действительно так. Понятие объект импортировано из логики, где кроме объектов есть ещё и субъекты. Разница между ними заключена, как известно, в том, что субъекты воздействуют на объекты. Но где можно найти формулировку субъекта в объектно-ориентированном программировании(ООП)? Т. е. попросту говоря, в ООП изначально неверно определены категории сущностей, что неизбежно заставляет ввести в ООП такие абстракции как «активный объект» (что на самом деле и является субъектом, хотя субъект не только не производное от объекта, а вообще независимая самостоятельная абстракция в логике).

Приверженцы ООП в качестве важного отличительного свойства этой парадигмы указывают на возможность наследования — отношения двух сущностей, когда одна из сущностей либо полностью, либо частично на основе наследования повторяет поведение и состояние другой сущности. Действительно, такое поведение часто встречается в реальном мире, и не лишено основания. Но, тем не менее, существующие попытки свести всю иерархию сущностей в одно дерево развития на самом деле мало чем оправдано и приводит к тому, что изменив базовую сущность автоматически происходит изменение и всех зависимых сущностей. И это не всегда удобно. Точнее даже, частенько это может грозить катастрофой программному проекту. Кроме того, существует огромное число объектов, для которых привязка к базовому типу совершенно необоснованна. Так например, такой ООП язык программирования, как Java принуждает программиста строить все объекты от встроенных. Из-за подобного жёсткого ограничения пришлось вводить возможность поломать это правило. Разумеется, это приводит к потенциальным нарушениям. В целом, ООП заметно облегчает декомпозицию программы, но в то же время привносит и свои сложности, в ключе понимания логики исполнения программы в целом. Компонентно-ориентированное программирование не принуждает программиста использовать какие-либо сущности. Язык и так достаточно строг, для того, чтобы программист не смог поломать свой код. Понятие сущности существенно совмещено с понятием модуля, и как правило, сущность содержится в одном модуле, что позволяет более полно контролировать логику программы. Впрочем, при явной необходимости сущность может быть распределена между многими модулями (например, при случае объединении в одной сущности многих других меньших сущностей). При этом КОП, в отличии от ООП элегантно и естественно решают проблему хрупкого базового класса — множественное наследование попросту не нужно.

Полиморфизм в ООП (с точки зрения приверженцев ООП) является важной составляющей частью. Возможно, кому-то из программистов действительно удобно писать подобный код:

сахар =вода +углекислый_газ +ультрафиолет

Но стало ли понятней, что происходит в таком коде? Давайте взглянем на код написанный в функциональном стиле

сахар =СинтезироватьСахар(вода,углекислый_газ,ультрафиолет)

Здесь совершенно очевидно, что суть сахара не равна сути воды, углекислого газа или ультрафиолета. Между этими понятиями знак равенства слегка неадекватен. В указанном примере идёт явное превращение нескольких свойств в новое свойство, более неприводимое ни к одному из предыдущих. В самом деле, запись

вода =сахар - (углекислый_газ +ультрафиолет)

в корне не верна и даже эмоционально вызывает чувство протеста. Кроме того, до сих пор идут жаркие споры, а на сколько полиморфизм вообще является частью ООП? Существует достаточное число языков программирования в которых полиморфизм есть, а объектов -- нет!) Обратное утверждение также верно: существуют языки с парадигмой ООП, но в них нет перегрузки операторов. Очень спорно назвать такие языки не полностью отвечающими парадигме ООП.

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

Адрес публикации: https://www.prodlenka.org/metodicheskie-razrabotki/621498-statja-na-temu-komponentno-orientirovannoe-pr