Модель программирования COM
В этом уроке мы научимся разрабатывать приложения, которые реализуют функции СОМ-сервера и СОМ-контейнера. Известная вам технология OLE (Object Linking and Embedding) базируется на модели COM (Component Object Model), которая определяет и реализует механизм, позволяющий отдельным компонентам (приложениям, объектам данных, элементам управления, сервисам) взаимодействовать между собой по строго определенному стандарту.
Технология разработки таких приложений кажется довольно сложной для тех, кто сталкивается с ней впервые. Трудности могут остаться надолго, если не уделить достаточно времени самым общим вопросам, то есть восприятию концепции СОМ (Модель многокомпонентных объектов). Поэтому не жалейте времени и пройдите через все, даже кажущиеся примитивными, этапы развития СОМ-приложений, как серверов, так и контейнеров. Мы начнем с того, что создадим СОМ-сервер с помощью сырых (raw) COM API-функций для того, чтобы лучше понять механизмы взаимодействия компонентов. Эти механизмы будут частично скрыты в следующих приложениях, которые мы будем развивать на основе стартовых заготовок, созданных мастером Studio .NET в рамках возможностей библиотеки шаблонов ATL (Active Template Library).
Любой программный продукт представляет собой набор данных и функций, которые как-то используют, обрабатывают эти данные. Этот принцип, как вы знаете, лежит в основе ООП. Там класс инкапсулирует данные и методы, которые служат для управления ими. Сходный принцип используется и в модели программирования СОМ. СОМ-объектом (или OLE-объектом) называется такой программный продукт, который обеспечивает доступ к данным с помощью одного или нескольких наборов функций, которые называются интерфейсами.
В отличие от ООП, которое рассматривает интеграцию классов на уровне исходных модулей – текстов программ, СОМ рассматривает интеграцию компонентов на двоичном уровне, то есть на уровне исполняемых модулей. Цель – многократное использование удачно разработанных компонентов именно на этом уровне. Двоичный уровень дает независимость от аппаратной архитектуры и языков программирования (взамен порождая массу других проблем). Двоичный стандарт взаимодействия позволяет СОМ-объектам, разработанным разными поставщиками и на разных языках, эффективно взаимодействовать друг с другом.
С практической точки зрения СОМ – это набор системных библиотек (DLL-файлов), которые дают возможность разным приложениям, выполненных с учетом требований СОМ, взаимодействовать друг с другом. Исторически сложилось так, что СОМ состоит из нескольких различных технологий, которые пользуются услугами друг друга для формирования объектно-ориентированной системы. Каждая технология реализует определенный набор функций.
Преимуществами двоичных компонентов являются: взаимозаменяемость, возможность многократного использования, возможность параллельной разработки с последующей сборкой в одном проекте. Недостатки СОМ настолько очевидны, что я не буду их перечислять. Вы почувствуете их в тот момент, когда начнете самостоятельно разрабатывать свой первый СОМ-объект. Приведем далеко не полный список литературы, который поможет более детально разобраться в технологии СОМ.
- Kraig Brockschmidt. Inside OLE 2nd Edition, MSDN, Books.
- Адам Деннинг. ActiveX для профессионалов. – СПб.: Питер, 1998.
- Д. Бокс. Сущность технологии СОМ. Библиотека программиста. – СПб.: Питер, 2001.
- С. Холзнер. Visual C++6: учебный курс. – СПб.: Питер, 2001.
- Д. Круглински, С. Уингоу, Дж. Шеферд. Программирование на Microsoft Visual C++ для профессионалов. – СПб.: Питер, 2001.
- Д. Эпплман. Win32 API и Visual Basic. Для профессионалов (+CD). – СПб.: Питер, 2001.
СОМ реализует модель "клиент-сервер". Объекты, называемые серверами, предоставляют набор функций в распоряжение других объектов, называемых клиентами, но СОМ-объект может быть одновременно и клиентом, и сервером. Серверы всегда подчиняются спецификациям СОМ, в то время как клиенты могут быть как СОМ-объектами, так и не быть таковыми. Поставщик СОМ-объектов (сервер) делает объекты доступными, реализуя один или множество интерфейсов. Пользователь СОМ-объектом (клиент) получает доступ к объекту с помощью указателя на один или множество интерфейсов.
С помощью указателя клиент может пользоваться объектом, не зная даже как он реализован и где он находится, но быть при этом уверенным, что объект всегда будет вести себя одинаково. В этом смысле интерфейс объекта представляет собой некий контракт, обещающий клиенту надежное поведение, несмотря на язык и местоположение клиента. Благодаря этому решается проблема бесконечных обновлений версий сервера. Новая версия сервера просто добавляет новые интерфейсы, но никогда не изменяет старых. Клиент может либо пользоваться новым интерфейсом, если он о нем знает, либо не пользоваться им, а вместо этого пользоваться старым.
Добавление новых интерфейсов никак не влияет на работу клиентов, работающих со старыми. Кроме того, как нас уверяет документация, двоичный уровень делает компоненты независимыми от платформы клиента.