Сущность технологии СОМ. Библиотека программиста

Рассмотрим сервер, реализующий три класса: Gorilla, Chimp и Orangutan. Сервер, возможно, будет содержать шесть отдельных классов C++: три из них создают экземпляры каждого класса, а другие три – объекты класса для каждого класса. В соответствии с этим сценарием, серверная реализация DllGetClassObject будет выглядеть следующим образом:

STDAPI DllGetClassObject(REFCLSID rclsid, REFIID riid, void **ppv)

{

// define a singleton class object for each class

// определяем одноэлементный объект класса

// для каждого класса

static GorillaClass sgorillaClass;

static OrangutanClass sorangutanClass;

static ChimpClass schimpClass;

// return interface pointers to known classes

// возвращаем указатели интерфейсов известных классов

if (rclsid == CLSIDGorilla) return sgorillaClass.QueryInterface(riid, ppv);

else if (rclsid == CLSIDOrangutan)

return sorangutanClass.QueryInterface(riid, ppv);

else if (rclsid == CLSIDChimp) return schimpClass.QueryInterface(riid, ppv);

// if we get to here, rclsid is a class we don't implement,

// so fail with well-known error code

// если мы добрались сюда, то rclsid – это класс, который

// мы не реализуем, поэтому сбой с известным кодом ошибки

*ppv = 0;

return CLASSECLASSNOTAVAILABLE;

}

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

Следующий псевдокод показывает, как API-функция CoGetClassObject устанавливает связь с серверным DllGetClassObject:

// pseudo-code from OLE32.DLL

// псевдокод из OLE32.DLL

HRESULT CoGetClassObject(REFCLSID rclsid, DWORD dwClsCtx, COSERVERINFO *pcsi , REFIID riid, void **ppv)

{

HRESULT hr = REGDBECLASSNOTREG;

*ppv = 0; if (dwClsCtx & CLSCTXINPROC)

{

// try to perform inproc activation

// пытаемся выполнить внутрипроцессную активацию

HRESULT (*pfnGCO)(REFCLSID, REFIID, void**) = 0;

// look in table of already loaded servers in this process

// просматриваем таблицу уже загруженных серверов внутри

// этого процесса pfnGCO = LookupInClassTable(rclsid, dwClsCtx);

if (pfnGCO == 0) {

// not loaded yet!

// еще не загружен!

// ask class store or registry for DLL name

// запрашиваем DLL-имя в хранилище классов или в реестре

char szFileName[MAXPATH];

hr = GetFileFromClassStoreOrRegistry(rclsid, dwClsCtx, szFileName);

if (SUCCEEDED(hr))

{

// try to load the DLL and scrape out DllGetClassObject

// пытаемся загрузить DLL и вытащить DllGetClassObject

HINSTANCE hInst = LoadLibrary(szFileName);

if (hInst == 0) return COEDLLNOTFOUND;

pfnGCO = GetProcAddress(hInst, «DllGetClassObject»);

if (pfnGCO == 0) return COEERRORINDLL;

// cache DLL for later use

// кэшируем DLL для дальнейшего использования InsertInClassTable(rclsid, dwClsCtx, hInst, pfnGCO);

}

}

// call function to get pointer to class object

// вызываем функцию для получения указателя на объект класса

hr = (*pfnGCO)(rclsid, riid, ppv);

}

if ((dwClsCtx & (CLSCTXLOCALSERVER | CLSCTXREMOTESERVER)) && hr == REGDBECLASSNOTREG)

{

// handle out-of-proc/remote request

// обрабатываем внепроцессный/удаленный запрос

}

return hr;

}

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

// from APELIB.DEF

// из APELIB.DEF LIBRARY

APELIB EXPORTS DllGetClassObject private

Фактически в модели СОМ компоновщики предпочитают, чтобы во всех связанных с СОМ точках входа использовалось это ключевое слово.

Обобщения

В предыдущем примере интерфейс IApeClass рассматривался как интерфейс уровня класса, специфический для классов, которые объявляют интерфейс IАре из своих экземпляров. Этот интерфейс позволяет клиентам создавать новые объекты или находить существующие, но в любом случае результирующие объекты должны реализовывать интерфейс IАре . Если бы новый класс хотел разрешить клиентам создавать или находить объекты, несовместимые с IApe , то объект этого класса должен был бы реализовывать другой интерфейс. Поскольку создание и поиск объектов являются общими требованиями, которые большинство классов хотели бы поддерживать, СОМ определяет стандартные интерфейсы для моделирования поиска и создания объектов унифицированным образом (generically). Один стандартный интерфейс для поиска объектов назван IOleItemContainer:

// from oleidl.idl из oleidl.idl

[ object, uuid(0000011c-0000-0000-C000-000000000046) ]

interface IOleItemContainer : IOleContainer {

// ask for object named by pszItem

// запрашиваем объект, именованный

pszItem HRESULT Get0bject(

[in] LPOLESTR pszItem,

// which object? какой объект?

[in] DWORD dwSpeedNeeded,

// deadline

[in, unique] IBindCtx *pbc,

// binding info информация о связывании

[in] REFIID riid,

// which interface? какой интерфейс?

[out, iidis(riid)] void **ppv);

// put it here! разместим его здесь!

// remaining methods deleted for clarity

// остальные методы удалены для ясности

}

Отметим, что метод GetObject позволяет клиенту задавать тип результирующего интерфейсного указателя. Действительный класс результирующего объекта зависит от контекста и конкретной реализации IOleItemContainer . Следующий пример запрашивает объект класса Gorilla найти объект под именем «Ursus»: