1.4. Типы компонентов

Одна из причин отсутствия простого описания COM - наличие большого количества "стандартных" интерфейсов. IUnknown и IDispatch - наиболее распространенные, однако, есть и другие. Одни определяют взаимодействие компонента с контейнером, при размещении компонента в клиентской области окна приложения, аналогично визуальным элементам управления. Другие - работают аналогично элементам управления, размещаемым на Web-страницах, которые взаимодействуют с браузером. В дополнение к этому существует еще и путаница в терминах: COM, ActiveX, OLE, элементы управления и компоненты: Чтобы не путаться в возможных вариантах, следует ввести следующую классификацию компонентов: невизуальные компоненты, визуальные компоненты (которые будут называться элементами управления) и компоненты, уведомляющие клиента о наступлении событий. Между этими упрощенными группами возможны пересечения, и существует много других вариантов разбиения компонентов на группы в зависимости от их интерфейсов.

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

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

Работа с визуальными компонентами, или элементами управления, сложнее, поскольку нужно обеспечить контейнер, содержащий компонент, некоторой информацией о компоненте, так как компонент становится дочерним окном контейнера. Нужно также передавать некоторую информацию и от контейнера обратно компоненту, поскольку последнему нужно знать, как отрисовывать себя и как взаимодействовать с содержащим его контейнером. В приводимом ниже примере используются некоторые возможности класса CWnd библиотеки MFC, автоматизирующие большинство необходимых операций.

Визуальные COM-компоненты чаще называют управляющим элементами ActiveX или OLE (здесь используется этот термин только по отношению к компонентам, реагирующим на ввод пользователя). Примерами визуальных компонентов могут служить некоторые специфические элементы управления, например, циферблат, шкала, или компоненты, содержащие некоторые графические элементы, например индикатор радара.

Третий тип компонентов, о которых здесь пойдет речь, - это компоненты, уведомляющие клиента через точки взаимодействия (connection points) о наступлении событий (например, о нажатии кнопки мыши или о выполнении определенной вычислительной задачи), либо вызывающие определенные методы клиента для завершения выполнения каких-либо задач (в этом случае клиент обычно тоже является компонентом). В приводимом нижепримере видно, как использовать компоненты в обоих случаях.

Служба COM+ Event Service в Windows 2000 вводит абсолютно новые возможности маршрутизации и обработки сообщений от компонентов. По сравнению с традиционным механизмом, использующим для этих целей точки взаимодействия, новая модель более приспособлена к использованию в распределенных вычислениях и позволяет отделить компоненты от их клиентов при обработке событий. Подробности этого механизма - это отдельная тема.