Добрынин В.Ю. Технологии компонентного программирования

Подождите немного. Документ загружается.

Технологии компонентного программирования

Владимир Добрынин

Санкт-Петербургский Государственный Университет

vdobr@oasis.apmath.spbu.ru

Дата последней модификации - 23 января 2003 г.

Contents

z Процедурное, объектно-ориентированное и компонентное программирование

{ Процедурное программирование

{ Объектно-ориентированное программирование

{ Компонентное программирование

{ Эволюция распределенных систем

z Технология COM (Component Object Model - компонентная объектная модель) от Microsoft

{ Интерфейсы

{ Реализация интерфейсов - коклассы

{ Фабрики классов

{ Сервер в процессе клиента

{ Регистрация сервера в реестре

{ Клиент

{ Язык описания интерфейсов и библиотека типов

{ Прозрачность местоположения

 DLL сервер в суррогатном процессе

 Стандартный маршалинг

{ Потоковая модель и апартаменты

 Процесс и поток

 Апартаменты

z Технология COM+ от Microsoft

{ Архитектура COM+

{ Синхронизация

{ Распределенные транзакции

 Основные понятия

 Модель транзакций в COM+

{ Безопасность

 Kerberos

 Модель безопасности в COM+

{ Асинхронные компоненты ( Queued Components)

 MSMQ

 Архитектура асинхронных компонент

{ Модель событий

 Событийный класс

 Издатель, подписчик и подписка

 Фильтр на стороне издателя

 Фильтр на стороне подписчика

z .NET Framework от Microsoft

{ Введение

{ Интерфейсы

{ Сервер в процессе клиента

{ Регистрация сборки в Global Assembly Cache

{ Удаленный сервер

{ Обработка ошибок

{ Синхронизация

z .NET и аспектно-ориентированное программирование

{ Введение

{ Описание примера

{ Серверное приложение

{ Атрибут трассировки вызовов

{ Клиентское приложение

{ Атрибут синхронизации

{ Эксперименты

 Все компоненты размещаются в одном контексте

 Компоненты размещаются в двух контекстах, но в одном домене синхронизации

 Компоненты размещаются в трех контекстах и в двух доменах синхронизации

z Еще раз про атрибут синхронизации

{ Инициализация свойства синхронизации в домене синхронизации

 Критические секции

 Делегаты,

егистрация callback делегата в пуле рабочих потоков

 Возвращаемся к коду инициализации атрибута

{ Обработка вызова, извлекаемого из очереди вызовов

 Представление вызова в виде работы - экземпляра класса WorkItem

 Немного про асинхронные вызовы

 Немного про контекст вызова

 Возвращаемся к классу WorkItem

 Извлечение работы из очереди и ее выполнение

{ Перехват входящего вызова

 Формирование перехватчика входящих вызовов

 Как перехватчик обрабатывает синхронные вызовы

 Как свойство синхронизации обрабатывает инкапсулированный синхронный вызов, полученный от

перехватчика

 Как перехватчик обрабатывает асинхронные вызовы

 Как свойство синхронизации обрабатывает инкапсулированный асинхронный вызов, полученный от

перехватчика

{ Перехват исходящего вызова

 Формирование перехватчика исходящих вызовов

 Перехват исходящих синхронных вызовов

 Перехват исходящих асинхронных вызовов

Процедурное, объектно-ориентированное и компонентное

программирование

Процедурное программирование

Цель данного раздела состоит в демонстрации некоторых недостатков технологии процедурного программирования.

Рассмотрим программу на C++, в которой используется технология процедурного программирования. Пользователь вводит

информацию о некотором множестве книг и журналов. Для книги это автор, название, год издания. Для журнала - название, год и

номер. Далее эти данные могут как-то обрабатываться. Например, информация

о каждом издании может быть представлена в

стиле, принятом в определенном издательстве и определяющем порядок полей, шрифты, разделители и т.п. В данном случае

никакой обработки введенных данных не производится, и они просто выводятся на терминал по окончании ввода всех данных.

// Книги и журналы (процедурное программирование)

#include <iostream.h>

#include <string.h>

#define MAX_LENGTH 100 // максимальное число символов в имени

// автора или в названии издания

#define MAX_ID 100 // максимальное число изданий

// Книга

typedef struct {

char szAuthor[MAX_LENGTH]; // автор

char szTitle[MAX_LENGTH]; // название

int nYear; // год издания

} Book;

// Журнал

typedef struct {

char szTitle[MAX_LENGTH]; // название

int nYear; // год выпуска

int nNumber; // номер

} Journal;

// Массив изданий

typedef struct {

int nPubIdx; // индекс издания (1 - книга, 2 - журнал)

void* pPub; // указатель на издание

} Pub;

Pub aPub[MAX_ID];

int nNewID = 0; // индекс нового издания

// Прототипы глобальных функций

void DisplayBook(Book &book); // вывод описания книги

void DisplayJournal(Journal &journal); // вывод описания журнала

void NewBook(); // ввод данных о новой книге

void NewJournal(); // ввод данных о новом журнале

// Главная функция

void main() {

Book *pBook;

Journal *pJournal;

int nMenu, flag = 1;

while(nNewID < MAX_ID && flag)

{

// Вывод пунктов меню

cout << "Новое издание. Введите:" << endl;

cout<<" 1 для книги,\n 2 для журнала\n 3 - выход"<< endl ;

// Выбор пункта меню

cin >> nMenu;

switch (nMenu)

{ case 1 : NewBook(); break;

case 2 : NewJournal(); break;

default: flag = 0; break;

}

// Вывод описаний изданий

for (int id = 0; id < nNewID; id++)

{

switch (aPub[id].nPubIdx)

{ case 1 : pBook = (Book*) aPub[id].pPub;

DisplayBook(*pBook);

delete pBook;

break;

case 2 : pJournal = (Journal*) aPub[id].pPub;

DisplayJournal(*pJournal);

delete pJournal;

break;

}

// Реализация глобальных функций

void DisplayBook(Book &book) {

cout <<"BOOK: "<< endl;

cout <<"Author: "<< book.szAuthor << endl;

cout <<"Title: "<< book.szTitle << endl;

cout <<"Year: "<< book.nYear<< endl;

}

void DisplayJournal(Journal &journal) {

cout <<"JOURNAL: "<< endl;

cout <<"Title: "<< journal.szTitle << endl;

cout <<"Year: "<< journal.nYear<< endl;

cout <<"Number: "<< journal.nNumber<< endl;

}

void NewBook() {

char szBuffer[MAX_LENGTH];

int nY;

Book* pBook = new Book;

cout <<"Author :";

cin >> szBuffer;

strcpy(pBook->szAuthor, szBuffer);

cout<<"Title :";

cin >> szBuffer;

strcpy(pBook->szTitle, szBuffer);

cout<<"Year :"; cin >> nY;

pBook->nYear = nY;

aPub[nNewID].nPubIdx = 1;

aPub[nNewID++].pPub = pBook;

}

void NewJournal() {

char szBuffer[MAX_LENGTH];

int nY, nN;

Journal* pJournal = new Journal;

cout << "Title :";

cin >> szBuffer;

strcpy(pJournal->szTitle, szBuffer);

cout << "Year :"; cin >> nY;

pJournal->nYear = nY;

cout << "Number :"; cin >> nN;

pJournal->nNumber = nN;

aPub[nNewID].nPubIdx = 2;

aPub[nNewID++].pPub = pJournal;

}

Данный код содержит ряд недостатков, которые (хотя бы отчасти) можно объяснить стремлением придерживаться процедурного

подхода

z Наличие нескольких глобальных функциий и связанных с ними глобальных данных

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

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

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

работу

программиста.

z Хранение в массиве aPub не только указателя на издание (void* pPub), но и информации о типе издания (int nPubIdx)

Информация о типе необходима для выполнения явного преобразования типа

pBook = (Book*) aPub[id].pPub,

pJournal = (Journal*) aPub[id].pPub,

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

Объектно-ориентированное программирование

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

CPublication и производные от него классы CBook и CJournal. В главной функции в файле publications.cpp реализуется

основная бизнес-логика.

// Заголовочный файл CPublication.h для класса CPublication

#ifndef _CPUBLICATION_

#define _CPUBLICATION_

#define MAX_LENGTH 100 // максимальное число символов в

// имени автора и в названии публикации

// Базовый класс

class CPublication

{

public:

CPublication(); // конструктор

virtual ~CPublication(); // деструктор

virtual void Display(); // вывод описания публикации

protected:

char m_szTitle[MAX_LENGTH]; // название публикации

int m_nYear; // год издания

};

#endif

Следующий файл содержит реализацию класса CPublication

// Файл CPublication.cpp - реализация класса CPublication

#include "CPublication.h"

#include <iostream.h>

// Конструктор

CPublication::CPublication()

{

// Ввод года издания и названия

cout << "Year: ";

cin >> m_nYear;

cout<<"Title :";

cin >> m_szTitle;

}

// Деструктор

CPublication::~CPublication()

{

}

// Вывод описания публикации

void CPublication::Display()

{

cout <<"PUBLICATION: "<< endl;

cout <<"Title: "<< m_szTitle << endl;

cout <<"Year: "<< m_nYear<< endl;

}

Файлы CBook.h и CBook.cpp задают класс CBook.

// CBook.h

#ifndef _CBOOK_

#define _CBOOK_

#include "CPublication.h"

class CBook : public CPublication // класс CBook - производный от

// CPublication

{

public:

CBook(); // конструктор

virtual ~CBook(); // деструктор

virtual void Display(); // вывод описания книги

protected:

char m_szAuthor[MAX_LENGTH]; // имя автора

};

#endif

// CBook.cpp

#include <iostream.h>

#include "CBook.h"

// Конструктор

CBook::CPublication()

{

// Ввод имени автора

cout <<"Author :";

cin >> m_szAuthor;

}

// Деструктор

CBook::~CBook()

{

}

// Вывод описания книги

void CBook::Display()

{

cout <<"BOOK: "<< endl;

cout <<"Author: "<< m_szAuthor << endl;

cout <<"Title: "<< m_szTitle << endl;

cout <<"Year: "<< m_nYear<< endl;

}

Файлы CJournal.h и CJournal.cpp задают класс CJournal.

// CJournal.h

#ifndef _CJOURNAL_

#define _CJOURNAL_

#include "CPublication.h"

class CJournal : public CPublication // класс CJournal - производный

// от CPublication

{

public:

CJournal(); // конструктор

virtual ~CJournal(); // деструктор

virtual void Display(); // вывод описания журнала

protected:

int m_nNumber; // номер журнала

};

#endif

// CJournal.cpp

#include <iostream.h>

#include "CJournal.h"

// Конструктор

CJournal::CJournal(): CPublication()

{

// Ввод номера журнала

cout << "Number: ";

cin >> m_nNumber;

}

// Деструктор

CJournal::~CJournal()

{

}

// Вывод описания журнала

void CJournal::Display()

{

cout <<"Journal: "<< endl;

cout <<"Title: "<< m_nTitle << endl;

cout <<"Year: "<< m_nYear<< endl;

cout <<"Number: "<< m_nNumber<< endl;

}

И, наконец, файл publications.cpp с бизнес-логикой

// Книги и журналы (объектно-ориентированное программирование)

#include <iostream.h>

#include "CBook.h"

#include "CJournal.h"

#define MAX_ID 100 // максимальное число изданий

void main()

{

int nMenu, flag = 1;

int nNewID = 0; // индекс нового издания

CPublication* aCPublication[MAX_ID]; // массив изданий

while(nNewID < MAX_ID && flag)

{

// Вывод пунктов меню

cout << "Новое издание. Введите:"<< endl ;

cout<<" 1 для книги,\n 2 для журнала\n 3 - выход" << endl ;

// Выбор пункта меню

cin >> nMenu;

switch (nMenu)

{ case 1 : aCPublication[nNewID++] = new CBook(); break;

case 2 : aCPublication[nNewID++] = new CJournal(); break;

default: flag = 0; break;

}

// Вывод описаний изданий

for (int id = 0; id < nNewID; id++)

{

aCPublication[id]->Display();

delete aCPublication[id];

}

В данном примере демонстрируется использование основных принципов объектно-ориентированного программирования

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

Инкапсуляция означает сокрытие от пользователя класса его внутренней кухни. Данные и функции (методы) хранятся

вместе, доступ к данным (которые следует размещать в защищенной секции

protected или private) доступен только с

помощью методов класса. Это позволяет разработчику класса менять код класса не изменяя код использующих его

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

z Наследование реализации

Цель механизма наследования - повторное использование кода. Класс

B, наследующий класс A, наследует его данные и

методы.

z Полиморфизм

Так как и класс

CBook, и класс CJournal происходят от одного базового класса CPublication, а метод Display() в базовом

классе является виртуальным, все производные от этого базового класса классы могут переопределить этот метод. Таким

образом, мы имеем возможность вызывать метод Display() для любого объекта любого класса порожденного от

CPublication и не беспокоиться при этом о выяснении типа объекта.

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

не решаемые ООП:

z Повторное использование кода

Это одна из целей ООП. Возможны два подхода:

{ Распространение библиотек классов в виде исходного кода (``белый ящик'')

Этот способ часто используется, т.к. библиотека будет компилироваться на машине клиента и, следовательно, не

будет проблем с несовместимостью различных компиляторов.

Но с этим способом связаны следующие проблемы:

 Многие программисты предпочитают писать свой код, а не изучать чужой.

 После изучения кода библиотеки часто возникает соблазн его модификации, адаптации под конкретное

приложение. В результате принцип повторного использования кода нарушается, т.к. приложение не сможет

использовать новые версии этой библиотеки.

 Код библиотеки включается в код всех использующих ее приложений.

{ Упаковка класса в динамически компонуемую библиотеку (DLL)

При этом мы избавляемся от проблем, возникающих при распространении классов в виде исходного кода. Но,

естественно, возникают новые проблемы:

 Отсутствие двоичного стандарта для C++

Различные компиляторы с C++ по разному решают вопросы реализации отдельных языковых особенностей

языка C++ и некоторые вопросы компоновки. В связи с этим, в общем случае нельзя гарантировать, что DLL,

подготовленная на одном компиляторе, будет работать с клиентом, подготовленным с помощью другого

компилятора.

 Проблема версий DLL

C++ поддерживает синтаксическую инкапсуляцию, но не двоичную. Иными словами, от клиента скрыта

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

этом перекомпиляция клиента в общем случае необходима. Это связано с тем, что именно клиент отводит

память под все данные экземпляра класса.

Это делается ради повышения эффективности. В результате, если при

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

новей версией DLL без перекомпиляции. Установив новую версию DLL, мы погубим все приложения, которые

были скомпилированы для работы со старой версией.

z Не решены вопросы разработки распределенных приложений

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

приложений становится необходимым требованием.

Компонентное программирование

В данном разделе будет дано только очень короткое введение в проблематику компонентного программирования. Подробнее - в

последующих главах.

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

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

строго определенные

интерфейсы, что позволяет снять проблему несовместимости компиляторов и обеспечивает смену версий

классов без перекомпиляции использующих их приложений.

Здесь стоит отметить, что роль интерфейсов в COM значительно более важная, чем роль посредника. Все в COM начинается с

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

заданный интерфейс, обеспечивая

тем самым полиморфизм на новом уровне.

Имеются различные технологии, реализующие парадигму компонентного программирования. Среди них COM (DCOM, COM+),

CORBA, .Net.

Для определенности остановимся на подходе, используемом в COM.

Компонент - это хранилище (в виде DLL или EXE файла) для одного или нескольких классов. Все, что знает клиент о классе, это

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

доступ к реализованным данным классом

методам. Допускается реализация компонента и использующего его клиента на различных языках (Visual C++, Visual Basic). В

реестре системы хранится информация о местоположении компонента, содержащего данный класс (на локальном или удаленном

компьютере). Это позволяет системе прозрачно для клиента перенаправлять вызовы методов к нужному компоненту и

возвращать результаты.

Таким образом, обеспечивается выполнение

двух важных принципов компонентного программирования:

z независимость от языка программирования,

z прозрачность местоположения сервера для клиента.

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

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

В COM инкапсуляция находится на более высоком уровне чем в ООП. Между клиентом и реализацией класса находятся

интерфейсы. Интерфейс - абстрактный базовый класс, который не имеет элементов данных и который является прямым

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

который является потомком данного и, возможно

, еще других интерфейсов.

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

интерфейса со стороны клиента. Клиент без перекомпиляции может вызывать методы новой версии класса (при сохранении

интерфейса). Новая версия может иметь расширенную функциональность за счет добавления новых интерфейсов. Эти

новые интерфейсы могут использоваться новыми клиентами, старые

же клиенты продолжают работать со старыми

интерфейсами, не зная о существовании новых.

z Наследование интерфейсов

В отличие от ООП, технология компонентного программирования не поддерживает наследование реализации класса.

Наследуются только интерфейсы. Каждый интерфейс получает свой уникальный идентификатор и может реализовываться в

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

интерфейсам. Например, в COM, любой интерфейс должен наследовать стандартному интерфейсу IUnknown. Наследование

интерфейса в

частности означает, что при реализации методов нового интерфейса будут реализованы и все методы,

описанные в наследуемом интерфейсе.

А как же быть с идеей повторного использования кода? В рамках технологии компонентного программирования

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

добавить функциональность старого компонента к

функциональности нового. Это делается с помощью одного из двух

методов:

{ Контейнеризация

Новый компонент включает (с помощью наследования) в свой интерфейс интерфейс старого компонента и реализует

его методы просто вызывая методы старого компонента (делегирование). При этом старый компонент не знает, что он

работает в интересах другого компонента. Но и новый компонент не получает новую функциональность совершенно

задаром. Он вынужден быть посредником между

клиентом и старым компонентом, что, естественно, сказывается на

производительности.

{ Агрегация

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

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

работает посредником - вызовы клиента, относящиеся к старому компоненту, направляются прямо ему. Но клиент

этого не замечает, ему кажется, что он работает

с одним новым компонентом.

z Полиморфизм

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

(поддерживающем COM). Конечно, при этом не должна меняться семантика интерфейса. Иными словами, клиенту не

важно, кто и как реализовал интересующий его интерфейс. Во всех случаях он получит именно то, что ожидает.

z Бинарное представление

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

Это позволяет решить многие проблемы, упомянутые ранее при описании недостатков ООП, и, кроме того, дает новые

возможности. Например, использование различных языков программирования при реализации компонентов и

использующих их клиентов.

z Инфраструктура для распределенных приложений

Многое из этой области включается в саму архитектуру системы, реализующей технологию компонентного

программирования, многое обеспечивается в виде дополнительных сервисов.

Например, в случае COM, при размещении компонента и клиента в различных процессах (на одном или на разных

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

параметров

и возврат результатов. В качестве примера дополнительных сервисов, реализованных в COM+, можно

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

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

Эволюция распределенных систем

Коротко напомним напомним эволюцию, которую претерпели распределенные системы:

z Одноуровневая система

Все пользователи работают на терминалах, подключенных к одному компьютеру. Если кто-то запустил задачу, требующую

много процессорного времени, все остальные пользователи это сразу же замечают.

z Локальная вычислительная сеть персональных компьютеров

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

z Архитектура клиент/сервер

Это так называемая двухзвенная архитектура. Сервер (например, баз данных) ожидает запросы клиентов (например,

выраженные на SQL), обрабатывает запрос и возвращает результат клиенту. Клиенты работают с сервером независимо.

Целостность данных обеспечивается механизмом транзакций.

Еще один пример системы с такой архитектурой - поисковые системы типа Alta Vista, Google, Yandex. В отличие от

традиционных клиентов для работы

с сервером баз данных ( как правило, ``толстых'' клиентов, требующих специальной

процедуры установки на машине пользователя), упомянутые поисковые системы работают с ``тонким'' клиентом, например,

с браузером Internet Explorer, не зависящим от конкретного приложения.

Однако, в поисковых системах заранее фиксирована так называемая бизнес-логика, что и позволяет обойтись тонким

клиентом. В более сложных случаях

приложений на уровне предприятий в рамках архитектуры клиент/сервер

используются толстые клиенты, реализующие бизнез-логику конкретного рабочего места.

z Трехзвенная архитектура клиент/бизнес-логика/данные

Это современная архитектура, в которой бизнес-логика отделена от клиента и от данных. Отделение бизнес-логики от

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

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

данных тоже не

являются подходящими средами для реализации бизнес-логики. Это часто наследуемые системы, не поддерживающие

современные технологии. Отсюда логически вытекает необходимость отдельной реализации бизнес-логики, и

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

z Web сервисы

Это новая перспективная архитектура, обеспечивающая распределенность на новом уровне. Вместо покупки компонентов и

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

вызовы методов из компонентов, принадлежащих и поддерживаемых независимыми владельцами. Очевидно, что при

реальном использовании такой архитектуры возникнет много новых вопросов, например, связанных с

надежностью. Вряд

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

системы являются примерами систем, которые будут проектироваться с использованием Web сервисов. Данная технология

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

от Microsoft предоставляет технологию для разработки и использования Web сервисов.

Технология COM (Component Object Model - компонентная

объектная модель) от Microsoft

Перепишем приложение о книгах и журналах, используя идеологию модели COM - Component Object Model от Microsoft.

Изложение основ этой модели будет проведено на примерах.

Интерфейсы

Напомним, что в модели COM все основано на интерфейсах. Интерфейс - это контракт между реализующим данный интерфейс

компонентом и клиентом, представленный набором определений методов (ничего кроме определений методов в интерфейс

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

компонент, реализующий данный интерфейс, гарантирует полную

реализацию его семантики, т.е. определенный набор методов.

Часто базовую архитектуру COM определяют с помощью следующей формулы

Базовая архитектура COM = сервер/класс/интерфейс/метод

Компонент реализуется в виде сервера (одного из трех видов). Сервер является хранилищем для одного или нескольких классов.

Каждый класс реализует один или несколько интерфейсов. Каждый интерфейс определяет один или несколько методов и

обязательно наследует от стандартного интерфейса

IUnknown (прямо или косвенно).

Определим вначале абстрактный базовый интерфейс

IPub (публикация), от которого далее будут порождены интерфейсы IBook и

IJournal (книга и журнал). Здесь надо отметить, что в COM нет множественного наследования интерфейсов и каждый

пользовательский интерфейс должен порождаться от какого-либо другого интерфейса (хотя бы от

IUnknown). Определение этого

интерфейса

IPub в виде заголовочного файла для С++ (IPub.h) приводится ниже.

// IPub.h -- Базовый интерфейс публикации IPub

#ifndef _IPub_

#define _IPub_

#include <windows.h> // содержит все нужное для COM

DECLARE_INTERFACE_(IPub, IUnknown)

{

STDMETHOD(SetTitle)(BSTR bstrTitle) PURE;

STDMETHOD(SetYear)(int nYear) PURE;

STDMETHOD(GetInfo)(BSTR * pbstrInfo) PURE;

};

#endif

В данном примере определен интерфейс IPub, наследуемый от стандартного интерфейса IUnknown. В интерфейсе IPub

определены 3 метода:

z SetTitle - задание названия публикации,

z SetYear - задание года публикации

z GetInfo - получение информации о публикации.

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

#define DECLARE_INTERFACE_(iface, baseiface)

interface iface : public baseiface

#define STDMETHOD(method) virtual HRESULT __stdcall method

#define PURE = 0

Таким образом,

DECLARE_INTERFACE_(IPub, IUnknown)

означает, что IPub есть интерфейс (то же что и struct в С), порожденный от IUnknown, а

STDMETHOD(SetTitle)(BSTR bstrTitle) PURE

означает, что чисто виртуальный метод SetTitle возвращает стандартную для COM величину типа HRESULT - 32-битное

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

Очевидно, что возможность анализа ошибок очень важна в распределенных приложениях. При этом __stdcall означает, что

параметры метода заносятся в стек в порядке справа налево и перед возвратом функция удаляет из стека свои параметры.

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

интерфейса. Это только контракт, никак не ограничивающий конкретную реализацию. Для использования данного интерфейса

нужно определить класс,

наследующий этот интерфейс (и, возможно, другие интерфейсы), и уже реализовать этот класс.

Известно, что в разных языках программирования строки организованы различным образом. В COM выбрано представление

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

BSTR (BASIC String) есть

строка, представленная в формате Unicode (2 байта на один символ), с завершающим нулем и с префиксом (4 байта), хранящим

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

строками (которые для C++ будут продемонстрированы в последующих примерах).

И, наконец, напомним, что в реализации данного примера средствами

ООП в описании класса CPublication имелся метод

Display, который обеспечивал вывод информации о публикации на терминал.

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

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