Pull to refresh

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

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

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


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

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

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

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

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

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


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


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

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

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

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

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

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


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

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

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

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


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

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

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

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

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

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


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

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


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

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

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


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

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

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


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

Безопасное управление памятью


Управление памятью, в том числе сборка мусора, может осуществляться внутри среды автоматически или другим способом (например, благодаря иерархической организации структуры компонентов фреймворка).
Tags:
Hubs:
You can’t comment this publication because its author is not yet a full member of the community. You will be able to contact the author only after he or she has been invited by someone in the community. Until then, author’s username will be hidden by an alias.