Что такое компонента в программировании

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

Компонентный подход программирования широко поддерживается фреймворками (программными каркасами).

См. также

Примечания

Полезное

Смотреть что такое «Компонент (программирование)» в других словарях:

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

Компонентно-ориентированное программирование — Парадигмы программирования Агентно ориентированная Компонентно ориентированная Конкатенативная Декларативная (контрастирует с Императивной) Ограничениями Функциональная Потоком данных Таблично ориентированная (электронные таблицы) Реактивная … Википедия

Объектно-ориентированное программирование — Эта статья во многом или полностью опирается на неавторитетные источники. Информация из таких источников не соответствует требованию проверяемости представленной информации, и такие ссылки не показывают значимость темы статьи. Статью можно… … Википедия

Экстремальное программирование — Разработка программного обеспечения Процесс разработки ПО Шаги процесса Анализ • Проектирование • Программирование • Докумен … Википедия

Отражение (программирование) — У этого термина существуют и другие значения, см. Отражение. Для улучшения этой статьи желательно?: Перевести текст с иностранного языка на русский. Н … Википедия

Декларативное программирование — Парадигмы программирования Агентно ориентированная Компонентно ориентированная Конкатенативная Декларативная (контрастирует с Императивной) Ограничениями Функциональная Потоком данных Таблично ориентированная (электронные таблицы) Реактивная … Википедия

Внутрисхемное программирование — (англ. In System Programming, сокр. ISP) технология программирования электронных компонентов (ПЛИС, микроконтроллеры и т. п.), позволяющая программировать компонент, уже установленный в устройство. До появления этой… … Википедия

Метод (программирование) — У этого термина существуют и другие значения, см. Метод. Метод в объектно ориентированном программировании это функция или процедура, принадлежащая какому то классу или объекту. Как и процедура в процедурном программировании, метод состоит… … Википедия

КОМПОНЕНТНО-ОРИЕНТИРОВАННОЕ ПРОГРАММИРОВАНИЕ (КОП) — Парадигма программирования, ключевой фигурой которой является компонент (англ. component oriented programming, COP) Словарь бизнес терминов. Академик.ру. 2001 … Словарь бизнес-терминов

Листинг (программирование) — Исходный код, написанный на JavaScript Исходный код (также исходный текст) текст компьютерной программы на каком либо языке программирования. В обобщённом смысле любые входные данные для транслятора. Исходный код либо транслируется в… … Википедия

Источник

Идеология компонентно-ориентированного программирования

Недостатки ООП и трудности, возникающие при моделировании сложных систем

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

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

Зависимость от языка программирования и платформы. Функциональность объекта записывается в виде кода шаблона объекта – класса — на некотором языке программирования. Объекты, написанные на разных языках, могут иметь свою специфику и оказаться в конечном итоге несовместимы между собой.

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

Сложность контроля жизненного цикла объекта. Жизненный цикл объекта начинается с вызова конструктора и заканчивается вызовом деструктора. После уничтожения объекта вся информация о его состоянии теряется. В случае необходимости сохранять состояние объекта, программисту необходимо самому реализовывать часть функциональности CRUD и контролировать жизненный цикл объекта.

Основные особенности КОП и отличие компонента от объекта

Компонент как объект, функционирующий в рамках сложной системы с непредсказуемым поведением и большим временем жизни

Главное отличие компонента от объекта заключается в том, что компонент функционирует в среде как часть единой системы – «фреймворка». Фреймворк предоставляет унифицированный способ доступа к ресурсам среды в рамках компонентной модели. Под средой (или окружением) обычно понимается среда выполнения — вычислительное окружение, необходимое для выполнения программы. В конечном итоге компонент взаимодействует как с операционной системой/виртуальной машиной, так и с пользователем, БД, периферийными устройствами и прочими объектами реального мира, используя возможности фреймворка. В контексте жизненного цикла разработки ПО, под средой также может пониматься среда разработки, среда выполнения и т.п.

Компонент может рассматриваться как объект, к которому предъявлен ряд дополнительных требований для функционирования в сложных средах с элементами неопределенности. Базовый класс компонента должен содержать всю необходимую функциональность, которая позволяет называть компонент компонентом.

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

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

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

Различные жизненные циклы и среды

С точки зрения аспекта разработки ПО, жизненный цикл компонента обычно начинается после того, как код на некотором языке программирования скомпилирован в виде модуля (сборки) и установлен в среду проектирования.

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

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

Способность компонента к описанию собственных свойств и умений

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

В дополнение к привычным сущностям ООП мира – полям и методам, КОП предлагает новые концептуальные понятия – свойства, события, команды, модули и т.д.

Изменение внутреннего состояния компонента производится с помощью изменения соответствующих свойств.

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

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

Способность компонента сохранять и восстанавливать свое состояние

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

Способность к взаимодействию, при этом независимость компонентов друг от друга

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

При этом компонент не автономен – он находится в тесном взаимодействии со средой. О среде компонент знает ровно столько, сколько ему необходимо для реализации заявленной функциональности.

Миграция компонентов между средами вместо компиляции

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

Теоретически в КОП может и вовсе отсутствовать привычный этап компиляции. Функциональность компонента может «виртуально» существовать в базе данных или в файловой системе и загружаться или даже меняться по мере необходимости.

Дизайн вместо программирования

При сборке системы из компонентов становится возможным создавать сложные информационные системы без единой строки кода!

Источник

Инструменты пользователя

Инструменты сайта

Содержание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5. Контроль во время компиляции и исполнения

Эти две фазы гораздо более тесно связаны, чем в случае других парадигм программирования. Так как, например C++ не гарантирует исполнения кода во всех возможных случаях, в него с неизбежностью введены лексемы, служащие для перехвата исключений. И это, в целом, плохо. Такие лексемы говорят о том, что язык не был сконструирован, а скорее сочинён. Более того, наличие инструкций перехвата управления, вовсе не гарантирует отсутствие таких эффектов как улететь в космос (неправильное исполнение программы, которое может нанести существенный ущерб целостности структур данных). В КОП нет ничего подобного. Подобные лексемы избыточны и в-общем случае – бессмысленны. В то же время, вполне возможна ситуация, когда интерфейс модуля в КОП был изменён. В такой ситуации надстройка над средой исполнения, отвечающая за состыковку различных модулей в режиме исполнения заметит несоответствие типов и запретит передачу данных между несовместимыми модулями. Это позволит своевременно остановить распространение ошибки по всей программе между модулями, которые, возможно, даже не участвовали во взаимодействии двух первых несовместимых модулей. Такое правило контроля во время исполнения приводит к важному следствию: взаимодействие между модулями происходит только с помощью базовых типов (такие как, целые числа, вещественные числа, массив литер). Во время компиляции, все задействованные модули для разработки проверяются на согласованность со вновь создаваемым модулем, а если уже существующий модуль необходимо изменить — создаётся новый (с другими интерфейсами), либо изменяется содержимое существующего модуля (с учётом возможных последствий для зависимых модулей). Так, например, решается проблема «ада динамических библиотек». Кроме того, для контроля правильности исполнения программы, введены специальные средства контроля содержимого переменных на допустимые значения — инварианты (использование таких средств считается хорошим тоном). Инварианты в КОП используются в форме предусловий (в начале участка кода), постусловий (в конце участка кода), условий (в произвольном месте кода).

Различные модули в КОП, которые нужны для исполнения программы – «связываются» на этапе активации программы (или даже во время её исполнения). В отличии от КОП, в подавляющем числе других языков программирования это происходит на этапе компиляции. Такая жёстко «сшитая» программа уже не подлежит изменению, и это не редко бывает очень неудобным.

6. Отличительные особенности компонентно-ориентированного программирования

КОП, в чём-то расширяет, а в чём-то ограничивает другие идиомы программирования. Так, поддерживается функциональный стиль, но ограничиваются сторонние эффекты. Как такого в КОП нет понятия класса, но в то же время, структуры данных, и привязанные к ним процедуры в рамках модуля — вполне описывает понятие класса в ООП. Достаточно простые исходные лексемы позволяют строить (и поощряют такое построение) код, который хорошо согласуем, сильно типизирован, может быть расширен (как через исходный код, так и через скомпилированный в машинном виде). КОП, прежде всего, нацелен на устойчивую динамичную среду. Так например, возможна ситуация в ОС Linux, когда с помощью специальных механизмов в ряде случаев можно внести исправления прямо в работающее ядро, в Компонентном Паскале – динамически заменить один работающий модуль на другой не представляет сложности (за исключением тех случаев, когда происходит взаимодействие с внешними ресурсами, которые Компонентный Паскаль контролировать, по понятным причинам, – не может). Также следует упомянуть о том, что в компилируемых языках автоматическая уборка мусора не такая простая вещь. В динамических системах потребность в сборщике мусора обязательна. По сути, операционная система сама и является таким глобальным сборщиком мусора. Обычно, программист сам должен контролировать низкоуровневые операции с памятью, так как языки программирования и операционные системы, обычно, не имеют развитых средств управления памятью (хотя, изредка и попадаются приятные исключения, например операционная система Aos, написанная на прямом родственнике Компонентного Паскаля – Активном Обероне). И здесь не нарушается принцип абстракции. Используя КОП можно построить систему, в которой уборка мусора будет выполняться автоматически и абсолютно точно. Это можно достигнуть несколькими способами, и самый доступный из них – подсчёт ссылок на структуры данных. Если модуль, который обрабатывает какую-либо структуру выгружен из памяти – очевидно, эти данные уже никто не сможет обработать).

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

Сборщик мусора – это не часть программы. Это часть среды. Именно поэтому, освобождение памяти становится гарантированно правильным. Такой класс уязвимостей ПО, как переполнение стека становится вымирающим видом.

7. Примеры реализации компонентно-ориентированного программирования

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

8. Компонентный Паскаль

Источник