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

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

Компонентно-ориентированное программирование (component-oriented programming) — парадигма программирования, ключевой фигурой которой является компонент.

Существует область, в которой понятие интерфейса играет главенствующую роль.

Проблема поддержки версий:

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

Создание новых версий MS Word= Новые версии проверки орфографии

Обновление частей программы происходит независимо (т. е. программа не сразу обновляется).

Значит, можно использовать старую версию MS Word, имея при этом новую версию проверки орфографии (и наоборот).

Интерфейс-список функций (сервисов), предоставляемых объектом (например, модулем). Технически, интерфейс — список заголовков и методов без реализаций, но со спецификацией.

Иерархия интерфейсов — наследование (пополнение) имён.

Таким образом, проверка орфографии обязана сохранять (поддерживать) старые версии и может предоставлять новые версии (функции).

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

Объекты, реализующие интерфейсы

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

Если объектная иерархия реализуется постепенно (уточняются методы реализации и т. д.), то подобная иерархия имён реализует всё сразу. Такого рода объекты называются компонентами.

Частный случай общей проблемы взаимодействия программного обеспечения разных производителей на уровне исполняемого кода

Соглашения уровня операционной системы.

Модуль – один уровень программирования.

Исполняемый код:

(OLE(Object Linking and Embedding), Active Pluse, Com, Cobra)- многопользовательские системы — динамически связанные библиотеки

С каждой компонентой связано некоторое системное имя или глобально-уникальный идентификатор, т. е. GUID (Globally Unique Identifier). Каждая следующая версия может лишь пополнять другую (наследование имён).

Базовый интерфейс компонент

Query interface – запрос интерфейса по GUID. Если поддерживается, то получить ссылку на реализацию:

Сервер

То, что много клиентов может использовать иной сервер (компонента — сервер), порождает проблему сборки мусора.

Решение этой проблемы:

-Release (освобождение)

-AddRef (добавление ссылок)

Вызов сборщика мусора, если счётчик =0, если не является равным 0 , то уменьшает счётчик ссылок на 1.

Проблема множественности иерархий

Мышление в терминах иерархий (уточнение строения, уточнение поведения) естественно для человеческого мышления.

В несистематизированных и хорошо систематизированных областях построение иерархии — очень трудное дело. Ведь чтобы описать полнее ситуацию требуется много иерархий.

Проектирование классов занимает до 80% всего времени разработки.

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

Проблемы:

1)  коллизия имён

2)  коллизия реализации

Общий подход к решению:

— одну иерархию рассматривать как основную: иерархия классов, наследование реализации

— другие иерархии связывать с иерархиями интерфейсов: наследование имён

«Симметричное» решение – агрегаты (декартовы произведения классов)

Агрегирование- возможность использования в качестве полей классов (т. е. ссылки на другие классы).

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

Эта проблема решается разделением существительных и прилагательных:

— выделить нечто главное как существительное

— рассмотреть иные иерархии, а затем выразить нечто вторичное в виде прилагательных (это чётко видно в именах)

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

Пример:

cEva

Class сChildren

{

cDad Dad;