§ 6.  Компоненты.

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

Рис. 6.1 Разбиение монолитного приложения на компоненты.

По мере развития технологии компоненты, составляющие приложение, могут заменяться новыми:

Рис. 6.2 Замена компонент D на новую, улучшенную версию.

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

§ 6.1  Преимущества использования компонентов.

Преимущества программ из компонентов связаны с:

1)     адаптацией приложений к нуждам пользователя;

2)     библиотеками компонентов;

3)     распределенными компонентами.

1. Адаптация приложений.

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

Например:

Рис. 6.3. Создание приложений из компонентов упрощает адаптацию. Пользователь 1 предпочитает редактор Vi, а пользователь 2 – Emacs.

2. Библиотеки компонентов.

Рис. 6.4. Из компонентов создаются библиотеки, используя которые можно быстро разрабатывать приложения.

Сборка приложений из стандартных блоков началась с создания управляющих элементов ActiveX (ранее известных как управляющие элементы OLE).

3. Распределенные компоненты.

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

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

Компонентное приложение с удаленными компонентами.

Рис. 6.5. Расположение компонентов на удаленных машинах в сети.

Компоненты C и D расположены в сети на двух удаленных машинах. На локальной машине они заменяются двумя новыми компонентами, переадресовщиками C и D. Последние переправляют запросы от других компонентов к удаленным C и D по сети. При наличии подходящих переадресующих компонентов приложение может игнорировать фактическое местоположение своих частей.

§ 6.2  Требования к компонентам.

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

Во-первых, они должны компоноваться динамически.

Во-вторых, они должны скрывать (или инкапсулировать) детали своей реализации.

Динамическая компоновка.

Возможность заменять компоненты во время работы приложения. Динамическая компоновка требует инкапсуляции.

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

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

Изменив способ подключения компонента к другим компонентам, мы разрушаем всю систему и должны перекомпилировать, если не переписать все заново.

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

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

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

1. Компоненты COM состоят из исполняемого кода, распространяемого в виде динамически компонуемых библиотек (DLL) или EXE-файлов Win32.

2. Для обеспечения взаимозаменяемости, компоненты должны быть инкапсулированы.

Инкапсуляция в компонентах COM достигается легко, поскольку они удовлетворяют следующим ограничениям:

·        Компоненты COM независимы от языка программирования (они могут быть разработаны с помощью любого процедурного языка ADA, C, Java, Modula -3, oberon, Pascal).

·        Компоненты COM могут распространяться в двоичной форме.

·        Компоненты COM можно модернизировать, не нарушая работы старых клиентов.

·        Компоненты COM можно прозрачно перемещать по сети.