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

Как подчеркивалось в этой главе, основные примитивы активации СОМ требуют, чтобы вызывающей программе при создании новых экземпляров класса было известно его точное имя. Иногда, однако, бывает полезно просто потребовать, чтобы подходящим являлся любой класс, удовлетворяющий некоторым семантическим ограничениям. Кроме того, прежде чем сделать запрос на активацию, было бы полезно знать, какие сервисные средства класс требует от своих клиентов. В этом случае не будут создаваться объекты, которые клиент не готов должным образом поддерживать. Эти проблемы послужили причиной для создания категорий компонентов (component categories).

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

Категория компонентов есть группа логически родственных СОМ-классов, которые разделяют общий ID категории, или CATID. Идентификаторы категории CATID — это GUID, записанные в реестре как атрибуты класса. Каждый класс может иметь два подключа: Implemented Categories и Required Categories (реализованные категории и нужные категории). Представим, что есть две категории компонентов: Simians и Mammals (приматы и млекопитающие). Каждая из этих двух категорий будет иметь уникальный CATID (CATID_Simians и CATID_Mammals соответственно). Допустим, что класс Chimp является членом каждой из этих категорий, и тогда для Chimp ключ реестра Implemented Categories будет содержать в себе каждый GUID как отдельный подключ:

[HKCR\CLSID\{CLSID_Chimp}\Implemented Categories\{CATID_Mammals}]

[HKCR\CLSID\{CLSID_Chimp}\Implemented Categories\{CATID_Simians}]

Классы

int cGorillas = Gorilla::GetCount(); IApe *pApe = new Gorilla(); pApe->GetYourStinkingPawsOffMeYouDamnDirtyApe();

Charleton Heston, 1968

В предыдущей главе обсуждались принципы интерфейсов СОМ вообще и интерфейс IUnknown в частности. Были показаны способы управления указателями интерфейса из C++, и детально обсуждалась фактическая техника реализации IUnknown. Однако не обсуждалось, как обычно клиенты получают начальный указатель интерфейса на объект, или как средства реализации объекта допускают, чтобы их объекты могли быть обнаружены внешними клиентами. В данной главе демонстрируется, как реализации объектов СОМ интегрируют в среду выполнения СОМ, чтобы дать клиентам возможность найти или создать объекты требуемого конкретного типа.

Классы и IDL

Как уже отмечалось в начале этой главы, СОМ рассматривает интерфейсы и классы как отдельные сущности. В свете этого классы СОМ (а равно и интерфейсы СОМ) должны быть определены в IDL с целью обеспечить независимое от языка описание конкретных типов данных, которые может экспортировать сервер. IDL-определение класса СОМ содержит список интерфейсов, которые экспортируются элементами класса, исключая катастрофический сбой:

[uuid(753A8A7D-A7FF-11d0-8C30-0080C73925BA)] coclass Gorilla { interface IApe; interface IWarrior; }

IDL-определения коклассов (coclass) всегда появляются в контексте определения библиотеки (library definition). В IDL определения библиотек используются для группирования набора типов данных (например, интерфейсы, коклассы, определения типов) в логический блок или пространство имен. Все типы данных, появляющиеся в контексте определения библиотеки IDL, будут отмечены в результирующей библиотеке типов. Библиотеки типов используются вместо IDL-файлов такими средами, как Visual Basic и Java.

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

// apes.idl // bring in IDL definitions of ape interfaces // введем IDL-определения интерфейсов обезьян import "apeitfs.idl"; [ uuid(753A8A80-A7FF-11d0-8C30-0080C73925BA), // LIBID - идентификатор библиотеки version(1.0), // version number of library - номер версии библиотеки lcid(9), // locale ID of library (english) // код локализации библиотеки (english) helpstring("Library of the Apes") // title of library - заголовок библиотеки ] library ApeLib { importlib("stdole32.tlb");

// bring in std defs. - вносим стандартные опредепения

[uuid(753A8A7D-A7FF-11d0-8C30-0080C73925BA)] coclass Gorilla { [default] interface IApe; interface IWarrior; }

[uuid(753A8A7E-A7FF-11d0-8C30-0080C73925BA)] coclass Chimpanzee { [default] interface IApe; interface IEgghead; }

Классы и серверы

СОМ-сервер — это двоичный файл, содержащий код метода для одного или более СОМ-классов. Сервер может быть упакован или в динамически подключаемую библиотеку (DLL), или в нормальный исполняемый файл. В любом случае за загрузку любого типа сервера автоматически отвечает диспетчер управления сервисами SCM.

Если в запросе на активацию объекта указана внутрипроцессная активация, то вариант сервера на базе DLL должен быть доступен для загрузки в адресном пространстве клиента. Если же в запросе на активацию указаны внепроцессная или внехостовая активация, то для запуска серверного процесса на указанной хост-машине (она может совпадать с машиной клиента) будет использован исполняемый файл. СОМ поддерживает также выполнение DLL-серверов в суррогатных процессах (surrogate processes) с целью разрешить использование внепроцессной и внехостовой активации существующих внутрипроцессных серверов. Подробности того, как суррогатные процессы связаны с внепроцессной и внехостовой активацией, будут изложены в главе 6.

Чтобы клиенты могли активировать объекты, не беспокоясь о том, как упакован сервер или где он инсталлирован, в СОМ предусмотрена конфигурационная база данных, отображающая CLSID на тот сервер, который реализует этот класс. При использовании версий Windows NT 5.0 или выше основным местом расположения этой конфигурационной базы данных является директория NT (NT Directory). Эта директория является рассредоточенной защищенной базой данных, в которой хранится служебная информация об учетных записях пользователей, хост-машинах и прочее. С тем же успехом в директории NT можно хранить информацию и о СОМ-классах. Эта информация записывается в области директории, называемой СОМ Class Store (хранилище СОМ-классов). СОМ использует Class Store для перевода CLSID в файлы реализации (в случае локальных запросов на активацию) или в удаленные хост-имена (в случае удаленных запросов на активацию). Если запрос на активацию для CLSID сделан на данной машине, то в первую очередь опрашивается локальный кэш.
Если в локальном кэше нет доступной конфигурационной информации, то СОМ посылает запрос в Class Store о том, чтобы реализация стала доступной из локальной машины. Это может просто означать добавление некоторой информации в локальный кэш, чтобы переадресовать запрос на другую хост-машину, или же это может привести к загрузке реализации класса на локальную машину и к запуску программы инсталляции. В любом случае, если класс зарегистрирован в Class Store, он доступен для запроса на активацию со стороны клиента в рамках ограничений безопасности.

Локальный кэш, упоминавшийся при обсуждении Class Store, официально называется системным реестром, или базой конфигурации системы (Registry). Реестр является иерархической базой данных, хранящейся в файлах на каждой машине, которую СОМ использует для преобразования CLSID в имена файлов (в случае локальной активации) или удаленные имена хостов (в случае удаленной активации). До Windows NT 5.0 реестр был единственным местом размещения конфигурационной информации СОМ. Быстрый поиск в реестре может быть осуществлен с помощью иерархических ключей (keys), имена которых представляют собой строки, разделенные обратными косыми чертами. Каждый ключ в реестре может иметь одно или несколько значений, которые могут иметь в своем составе строки, целые значения или двоичные данные. В реализации СОМ на Windows NT 4.0 большая часть ее конфигурационной информации записывается под именем

HKEY_LOCAL_MACHINE\Software\Classes

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

HKEY_CLASSES_ROOT

Реализация СОМ на Windows NT 5.0 продолжает использовать HKEY_CLASSES_ROOT для установок в рамках всей машины, но также разрешает каждому пользователю назначить свою конфигурацию CLSID для обеспечения большей безопасности и гибкости. Под Windows NT 5.0 СОМ вначале опрашивает

HKEY_CURRENT_USER\Software\Classes

прежде чем опрашивать HKEY_CLASSES_ROOT. Для удобства записи часто используются аббревиатуры HKLM, HKCR и HKCU вместо HKEY_LOCAL_MACHINE, HKEY_CLASSES_ROOT и HKEY_CURRENT_USER, соответственно.



СОМ хранит информацию, относящуюся к CLSID всех машин, под ключом реестра

HKCR\CLSID

В версии Windows NT 5.0 или выше СОМ ищет информацию о классах каждого пользователя под ключом

HKCU\Software\Classes\CLSID

Под одним из этих ключей будет сохранен список локальных CLSID, для каждого CLSID — свой подключ. Например, класс Gorilla, использовавшийся ранее в этой главе, мог бы иметь по всей машине запись по подключу:

[HKCR\CLSID\{571F1680-CC83-11d0-8C48-0080C73925BA}] @="Gorilla"

Для обеспечения локальной активации объектов Gorilla запись для CLSID Gorilla в реестре должна иметь подключ, показывающий, какой файл содержит исполняемый код для методов класса. Если сервер упакован как DLL, то требуется такая запись:

[HKCR\CLSID\{571F1680-CC83-11d0-8C48-0080C73925BA}\InprocServer32] @="C:\ServerOfTheApes.dll"

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

[HKCR\CLSID\{571F1680-CC83-11d0-8C48-0080C73925BA}\LocalServer32] @="С:\ServerOfTheApes.exe"

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

[HKCR\CLSID\{571F1680-CC83-11d0-8C48-0080C73925BA}\ProgID] @="Apes.Gorilla.1"

Наоборот, для поддержки функции CLSIDFromProgID требуются следующие величины:

[HKCR\Apes.Gorilla.1] @="Gorilla" [HKCR\Apes.Gorilla.1\CLSID] @="\{571F1680-CC83-11d0-8C48-0080C73925BA}

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

Все стандартно реализованные серверы СОМ поддерживают саморегистрацию. Для внутрипроцессного сервера это означает, что DLL должен экспортировать известные функции

STDAPI DllRegisterServer(void); STDAPI DllUnregisterServer(void);

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


Эти подпрограммы должны быть явно экспортированы с использованием или файла определения модуля, или переключателей компоновщика, или директив компилятора. Эти подпрограммы используются хранилищем классов Class Store для конфигурирования локального кэша после загрузки файла на машину клиента. Кроме Class Store эти известные подпрограммы используются различными средами (например, Microsoft Transaction Server, ActiveX Code Download, а также различными инсталляционными программами) для инсталляции или деинсталляции серверов на хост-машинах. В Win32 SDK включена утилита REGSVR32.EXE, которая может инсталлировать или деинсталлировать внутрипроцессный сервер СОМ с использованием этих известных экспортированных функций.

Реализации внутрипроцессных серверов DllRegisterServer и DllUnregisterServer должны запросить реестр на добавление или удаление соответствующих ключей, преобразующих CLSID и ProgID сервера в файловые имена сервера. Хотя существуют различные способы реализации этих подпрограмм, наиболее гибким и эффективным из них является создание строковой таблицы, содержащей соответствующие ключи, названия величин, сами величины и простое перечисление всех записей в таблице, путем вызова RegSetValueEx для инсталляции и RegDeleteKey для деинсталляции. Чтобы осуществить регистрацию, основанную на этой технологии, сервер может просто задать массив строк размером Nx3, где каждый ряд массива содержит строки для использования в качестве ключей, имена величин и величины:

const char *g_RegTable[][3] = { // format is { key, value name, value } { "CLSID\\{571F1680-CC83-11d0-8C48-0080C73925BA}", 0, "Gorilla" }, { "CLSID\\{571F1680-CC83-11d0-8C48-0080C73925BA}\\InprocServer32",0, (const char*)-1 // rogue value indicating file name // нестандартное значение, указывающее имя файла },

{ "CLSID\\{571F1680-CC83-11d0-8C48-0080C73925BA}\\ProgID", 0, "Ареs.Gorilla.1" },

{ "Apes.Gorillа.1", 0, "Gorilla" }, { "Apes.Gorilla.1\\CLSID", 0, "{571F1680-CC83-11d0-8C48-0080C73925BA}" }, };



Имея эту таблицу, весьма несложно осуществить реализацию DllRegisterServer:

STDAPI DllRegisterServer(void) { HRESULT hr = S_OK; // look up server's file name // ищем имя файла сервера char szFileName[MAX_PATH]; GetModuleFileNameA(g_hinstDll, szFileName, MAX_PATH); // register entries from table // регистрируем записи из таблицы int nEntries = sizeof(g_RegTable)/sizeof(*g_RegTable); for (int i = 0; SUCCEEDED(hr) && i < nEntries; i++) { const char *pszKeyName = g_RegTable[i][0]; const char *pszValueName = g_RegTable[i][1]; const char *pszvalue = g_RegTable[i][2]; // map rogue value to module file name // переводим нестандарное значение в имя файла модуля if (pszValue == (const char*)-1) pszValue = szFileName; HKEY hkey; // create the key // создаем ключ long err = RegCreateKeyA(HKEY_CLASSES_ROOT, pszKeyName, &hkey); if (err == ERROR_SUCCESS) { // set the value // присваиваем значение err = RegSetValueExA(hkey, pszVvalueName, 0, REG_SZ, (const BYTE*) pszValue, (strlen(pszValue) + 1)); RegCloseKey(hkey); } if (err != ERROR_SUCCESS) { // if cannot add key or value, back out and fail // если невозможно добавить ключ или значение, то откат и сбой DllUnregisterServer(); hr = SELFREG_E_CLASS; } } return hr; }

Соответствующая DllUnregisterServer будет выглядеть так:

STDAPI DllUnregisterServer(void) { HRESULT hr = S_OK; int nEntries = sizeof(g_RegTable)/sizeof(*g_RegTable); for (int i = nEntries - 1; i >= 0; i--) { const char *pszKeyName = g_RegTable[i][0]; long err = RegDeleteKeyA(HKEY_CLASSES_ROOT, pszKeyName); if (err != ERROR_SUCCESS) hr = S_FALSE; } return hr; }

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



Так как СОМ преобразует CLSID в данный файл реализации, то для объявления в СОМ относящихся к серверу объектов класса необходимо использовать определенные стандартные методики. Для сервера, основанного на исполняемой программе, в СОМ предусмотрены явные API-функции для связывания объектов класса с их CLSID. Эти API-функции мы будем подробно обсуждать в главе 6. Для сервера, основанного на DLL, DLL должна экспортировать известную функцию, которая будет вызываться с помощью CoGetClassObject, когда потребуется объект класса. Эту функцию необходимо экспортировать с использованием файла определения модулей, причем она должна иметь следующий вид:

HRESULT DllGetClassObject( [in] REFCLSID rclsid, // which class object? // какой объект класса? [in] REFIID riid, // which interface? // какой интерфейс? [out, iid_is(riid)] void **ppv); // put it here! // разместить его здесь!

Для удобства и эффективности данный сервер может содержать код для более чем одного класса. Первый параметр DllGetClassObject показывает, какой класс в данный момент запрашивается. Второй и третий параметры просто дают функции возможность возвращать типизированный указатель интерфейса для СОМ.

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

STDAPI DllGetClassObject(REFCLSID rclsid, REFIID riid, void **ppv) { // define a singleton class object for each class // определяем одноэлементный объект класса // для каждого класса static GorillaClass s_gorillaClass; static OrangutanClass s_orangutanClass; static ChimpClass s_chimpClass; // return interface pointers to known classes // возвращаем указатели интерфейсов известных классов if (rclsid == CLSID_Gorilla) return s_gorillaClass.QueryInterface(riid, ppv); else if (rclsid == CLSID_Orangutan) return s_orangutanClass.QueryInterface(riid, ppv); else if (rclsid == CLSID_Chimp) return s_chimpClass.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 CLASS_E_CLASSNOTAVAILABLE; }



Заметим, что приведенный код не заботится о том, какой интерфейс объявляется каждым из объектов класса. Он просто отправляет запрос 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 = REGDB_E_CLASSNOTREG; *ppv = 0; if (dwClsCtx & CLSCTX_INPROC) { // 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[MAX_PATH]; 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 CO_E_DLLNOTFOUND; pfnGCO = GetProcAddress(hInst, "DllGetClassObject"); if (pfnGCO == 0) return CO_E_ERRORINDLL; // 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 & (CLSCTX_LOCAL_SERVER | CLSCTX_REMOTE_SERVER)) && hr == REGDB_E_CLASSNOTREG) { // handle out-of-proc/remote request // обрабатываем внепроцессный/удаленный запрос } return hr; }

Отметим, что реализация CoGetClassObject является единственным местом, откуда вызывается DllGetClassObject.


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

// from APELIB.DEF // из APELIB.DEF LIBRARY APELIB EXPORTS DllGetClassObject private

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

1

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

2

Приведенный здесь способ записи использует стандартный синтаксис REGEDIT4. Строки, содержащиеся внутри скобок, соответствуют именам ключей. Пары имя=значение (name = value) под ключом обозначают значения, присвоенные указанному ключу. Необычное имя "@" показывает значение ключа по умолчанию.

Моникеры и композиция

Моникеры часто составляются из других моникеров, чтобы с помощью текстового описания пути можно было осуществлять навигацию по иерархиям объектов. Чтобы обеспечить простую поддержку этого типа управления, в СОМ предусмотрена стандартная реализация моникеров, которая, будучи поставленной справа от другого моникера, запрашивает объект связать ссылку с другим объектом в иерархии. Такой моникер называется моникером элемента (Item Moniker) и использует интерфейс объекта IOleItemContainer для преобразования имени объекта в интерфейсный указатель.

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

clsid:571F1680-CC83-11d0-8C48-0080C73925BA:!Ursus

Отметим использование символа "!" для отделения отображаемого имени Class Moniker от имени элемента (item name) "Ursus". При анализе MkParseDisplayName сначала использует префикс "clsid" в качестве ProgID для контакта с реализацией Сlass Moniker. Затем MkParseDisplayName предложит реализации Class Moniker проанализировать часть строки — столько, сколько она сможет распознать. Это означает, что после того, как Сlass Moniker извлек свой GUID из строки, ее следующий фрагмент все еще нуждается в анализе:

!Ursus

Поскольку это имя имеет смысл только в области действия объекта, именованного моникером слева от него, фактически MkParseDisplayName присваивает значение крайнему левому моникеру (моникеру классового типа) и запрашивает объект, который он именует (объект класса Gorilla) проанализировать оставшуюся часть строки. Для поддержки анализа отображаемых имен СОМ определяет стандартный интерфейс IParseDisplayName:

[ object,uuid(0000011a-0000-0000-C000-000000000046) ] interface IParseDisplayName : IUnknown { // convert display name to a moniker // преобразуем отображаемое имя в моникер HRESULT ParseDisplayName( [in, unique] IBindCtx *pbc, [in] LPOLESTR pszDisplayName, [out] ULONG *pchEaten, [out] IMoniker **ppmkOut ); }

В случае отображаемого имени, использованного в этом примере, объекту класса Gorilla потребуется реализовать IParseDisplayName и преобразовать строку "!Ursus" в моникер, который MkParseDisplayName поставит справа от моникера классового типа.
Поскольку требуется стандартный моникер элемента, то достаточно будет такой реализации:

STDMETHODIMP GorillaClass::ParseDisplayName(IBindCtx *pbc, LPOLESTR pszDisplayName, ULONG *pchEaten, IMoniker **ppmkOut) { // create an item moniker using explicit API function // создаем отдельный моникер, используя явную API-функцию HRESULT hr = CreateItemMoniker(OLESTR("!"), pszDisplayName + 1, ppmkOut); // indicate how many characters were parsed // показываем, сколько символов было проанализировано if (SUCCEEDED(hr)) *pchEaten = wcslen(pszDisplayName); else *pchEaten = 0; return hr; }

Отметим, что в данном примере не делается попытки проверить правильность анализируемого имени. Здесь просто убирается начальный символ "!", и из оставшейся части отображаемого имени создается новый моникер элемента.

Так как было проанализировано два моникера, то MkParseDisplayName будет собирать эти моникеры вместе, используя групповой композитный моникер (generic composite moniker). Групповой композитный моникер просто удерживает два моникера вместе. Реализация группового композитного моникера BindToObject сначала связывает моникер справа, передавая ему указатель на моникер слева через параметр pmkToLeft. Это иллюстрируется следующим псевдокодом:

// pseudo-code from OLE32.0LL // псевдокод из OLE32.DLL STDMETHODIMP GenericComposite::BindToObject (IBindCtx *pbc, IMoniker *pmkToLeft, REFIID riid, void **ppv) { return m_pmkRight->BindToObject(pbc, m_pmkLeft, riid, ppv); }

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

Ранее мы установили, что моникер элемента использует интерфейс IOleItemContainer для связывания интерфейсного указателя. Ниже приведен псевдокод для реализации моникера элемента ВindToObject:

// pseudo-code from OLE32.DLL // псевдокод из OLE32.DLL STDMETHODIMP ItemMoniker::BindToObject( IBindCtx *pbc, IMoniker *pmkToLeft, REFIID riid, void **ppv) { // assume failure // допускаем возможность сбоя *ppv = 0; if (pmkToLeft == 0) //requires a scope - требуется область действия return E_INVALIDARG; // first bind moniker to left // сначала привязываем моникер слева IOleItemContainer *poic = 0; HRESULT hr = pmkToLeft->BindToObject(pbc, 0, IID_IOleItemContainer, (void**)&poic); if (SUCCEEDED(hr)) { // cache the bound object in binding context // кэшируем связанный объект в контексте связывания pbc->RegisterObjectBound(poic); // get bind speed from Bind Context // получаем быстроту связывания из контекста связывания DWORD dwBindSpeed = this->MyGetSpeedFromCtx(pbc); // ask object for named sub-object // запрашиваем объект об именованном подобъекте hr = poic->GetObject(m_pszItem, dwBindSpeed, pbc, riid, ppv); poic->Release(); } }



Эта реализация означает, что такой код:

HRESULT GetUrsus(IApe *&rpApe) { const OLECHAR pwsz[] = OLESTR("clsid:571F1680-CC83-11d0-8C48-0080C73925BA:!Ursus"); return CoGetObject(pwsz, 0, IID_IApe, (void**)&rpApe); }

эквивалентен следующему:

HRESULT GetUrsus(IApe *&rpApe) { IOleItemContainer *poic = 0; HRESULT hr = CoGetClassObject(CLSID_Gorilla, CLSCTX_ALL, 0, IID_IOleItemContainer, (void**)&poic); if (SUCCEEDED(hr)) { hr = poic->GetObject(OLESTR("Ursus"), BINDSPEED_INFINITE, 0, IID_IApe, (void**)&rpApe); poic->Release(); } return hr; }

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

Моникеры и сохраняемость

Обсуждение моникеров не может быть полным без обсуждения файлового моникера (File Moniker). Напомним, что СОМ предусматривает три примитива активации: привязывание к объектам класса, привязывание к новым экземплярам класса и привязывание к постоянным объектам, хранящимся в файлах. В данной главе детально анализировались первые два из этих примитивов. Третий примитив основан на API-функции СОМ CoGetInstanceFromFile:

HRESULT CoGetInstanceFromFile( [in, unique] COSERVERINFO *pcsi, // host/security info - информация о хосте/безопасности [in, unique] CLSID *pClsid, // explicit CLSID (opt) - явный CLSID (opt) [in, unique] IUnknown *punk0uter, // for aggregation - для агрегирования [in] DWORD dwClsCtx, // locality? - локализация? [in] DWORD grfMode, // file open mode - режим открытия файла [in] OLECHAR *pwszName, // file name of object - файловое имя объекта [in] DWORD cmqi, // how many interfaces? - сколько интерфейсов? [out, size_is(cmqi)] MULTI_QI *prgmq // where to put itfs - куда поместить интерфейсы );

Эта функция принимает на вход имя файла, которое относится к постоянному состоянию (persistent state) объекта. CoGetInstanceFromFile удостоверяется в том, что объект исполняется, после чего возвращает один или несколько интерфейсных указателей на (ре)активированный объект. Чтобы выполнить эту работу, CoGetInstanceFromFile в первую очередь требуется определить CLSID данного объекта. CLSID требуется по двум причинам. Если объект не исполняется, то CLSID необходим СОМ для создания нового экземпляра, который будет инициализирован от постоянного (находящегося в файле) образа. Во-вторых, если вызывающий объект не указывает определенное хост-имя до запроса на активацию, то СОМ будет использовать CLSID для выяснения того, на какой машине следует активировать объект.

Если CLSID не передается явно вызывающим объектом, то CoGetInstanceFromFile извлекает CLSID из самого файла с помощью вызова API-функции СОМ GetClassFile:

HRESULT GetClassFile([in, string) OLECHAR *pwszFileName, [out] CLSID *pclsid);

Объекты классов

Основное требование всех СОМ-классов состоит в том, что они должны иметь объект класса. Объект класса — это единственный экземпляр (синглетон), связанный с каждым классом, который реализует функциональность класса, общую для всех его экземпляров. Объект класса ведет себя как метакласс по отношению к заданной реализации, а реализуемые им методы выполняют роль статических функций-членов из C++. По логике вещей, может быть только один объект класса в каждом классе; однако в силу распределенной природы СOМ каждый класс может иметь по одному объекту класса на каждую хост-машину (host machine), на учетную запись пользователя или на процесс, — в зависимости от того, как используется этот класс. Первой точкой входа в реализацию класса является ее объект класса.

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

class GorillaClass : public IApe { public: // class objects are singletons, so don't delete // объекты класса существуют в единственном экземпляре, // так что не удаляйте их IMPLEMENT_UNKNOWN_NO_DELETE (GorillaClass) BEGIN_INTERFACE_TABLE(GorillaClass) IMPLEMENTS_INTERFACE(IApe) END_INTERFACE_TABLE() // IApe methods // методы IApe STDMETHODIMP EatBanana(void); STDMETHODIMP SwingFromTree(void); STDMETHODIMP get_Weight(long *plbs); };

Обобщения

В предыдущем примере интерфейс 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, iid_is(riid)] void **ppv); // put it here! разместим его здесь!

// remaining methods deleted for clarity // остальные методы удалены для ясности }

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

HRESULT FindUrsus(IApe * &rpApe) { // bind a reference to the class object // связываем ссылку с объектом класса rpApe = 0; IOleItemContainer *poic = 0; HRESULT hr = CoGetClassObject(CLSID_Gorilla, CLSCTX_ALL, 0, IID_IOleItemContainer, (void**)&poic); if (SUCCEEDED(hr)) { // ask Gorilla class object for Ursus // запрашиваем объект класса Gorilla на поиск Ursus hr = poic->GetObject(OLESTR("Ursus"), BINDSPEED_INDEFINITE, 0, IID_IApe, (void**)&rpApe); poic->Release(); } return hr; }

Оптимизации

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

HRESULT CreateChimp(/* [out] */ IApe * &rpApe) { extern const CLSID CLSID_Chimp; rpApe = 0; IClassFactory *pcf = 0; HRESULT hr = CoGetClassObject(CLSID_Chimp, CLSCTX_ALL, 0, IID_IClassFactory, (void**)&pcf); if (SUCCEEDED(hr)) { hr = pcf->CreateInstance(0, IID_IApe, (void**)&rpApe); pcf->Release(); } return hr; }

Этот код выполняет одну операцию: создание объекта Chimp. Заметим, что для выполнения одной операции понадобилось три вызова подопераций (suboperations) — CoGetClassObject, CreateInstance, Release. Если сервер загружен как внутрипроцессный, то эти три подоперации не обойдутся слишком дорого. Если, однако, сервер является внепроцессным или внехостовым, то каждая из этих подопераций потребует вызова между процессами клиента и сервера. Хотя СОМ использует очень эффективную передачу IPC/RPC (Interprocess Communication/Remote Procedure Call), каждая из этих подопераций потребует немалых исполнительных затрат. В идеале было бы лучше потребовать, чтобы СОМ перешел на серверный процесс один раз и, находясь там, использовал объект класса для вызова CreateInstance от имени клиента. Если объект класса используется только для реализации IClassFactory, то этот способ будет более эффективным, чем трехшаговый способ, показанный ранее. В СОМ имеется API-функция: CoCreateInstanceEx, относящаяся по своему назначению к той же категории, что CoGetClassObject и IClassFactory::CreateInstance — обеспечивающая создание новых объектов за одно обращение между процессами.

CoCreateInstanceEx дает клиенту возможность задать CLSID для определения, какой объект следует реализовать. В случае успешного выполнения СоСгеаteInstanceEx возвращает один или более указателей интерфейса, которые ссылаются на новый экземпляр заданного класса.
При использовании CoCreateInstanceEx клиент никогда не видит промежуточный объект класса, который используется для создания экземпляра объекта. Чтобы клиенты могли вызывать CoCreateInstanceEx, никаких дополнительных функций серверу реализовывать не нужно. С точки зрения сервера все, что необходимо, — это объявить свои объекты классов, как требуется для CoGetClassObject. Реализация CoCreateInstanceEx для нахождения соответствующего объекта класса будет использовать ту же технологию, что и CoGetClassObject. Основное различие заключается в том, что после нахождения объекта CoCreateInstanceEx выполняет дополнительный вызов IClassFactory::CreateInstance, за которым могут последовать один или более вызовов QueryInterface, и все это во время выполнения процесса объекта класса. Можно получить значительную экономию на этапе выполнения, если запрос на активацию закрепить за определенным процессом.

Подобно CoGetClassObject, CoCreateInstanceEx позволяет клиенту задавать желаемые параметры CLSCTX и COSERVERINFO. Кроме того, CoCreateInstanceEx дает клиенту возможность запрашивать более одного указателя интерфейса на вновь создаваемый объект. Это делается путем предоставления клиенту возможности передавать массив структур MULTI_QI, который будет использован для вызова QueryInterface, новому экземпляру во время выполнения серверного процесса:

typedef struct tagMULTI_QI { // which interface is desired? // какой интерфейс требуется? const IID *piid; // null on input, will contain the pointer on output // на входе нуль, на выходе будет содержать указатель [iid_is(piid)] IUnknown *pItf; // will contain the HRESULT from QueryInterface on output // на выходе будет содержать HRESULT от QueryInterface HRESULT hr; } MULTI_QI;

Так как клиент может запрашивать более чем один указатель интерфейса на новый объект, он более не нуждается в явном вызове QueryInterface, если ему требуется более чем один тип указателей интерфейса. Поскольку эти вызовы QueryInterface будут сделаны СОМ от имени клиента по время выполнения внутри процесса объекта класса, более не потребуется никаких обменов данными между клиентом и объектом.


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

После постижения структуры MULTI_QI понять определение CoCreateInstanceEx уже нетрудно:

HRESULT CoCreateInstanceEx( [in] REFCLSID rclsid, // what kind of object? - какого сорта объект? [in] IUnknown *pUnkOuter,// for aggregation - для агрегирования [in] DWORD dwClsCtx, // locality? - размещение? [in] COSERVERINFO *pcsi, // host/security info - информация о хосте/безопасности [in] ULONG cmqi, // how many interfaces? - сколько интерфейсов? [out, size_is (cmqi)] MULTI_QI *prgmq // where to put itfs — куда разместить интерфейсы );

Если все запрошенные интерфейсы доступны в новом объекте, то CoCreateInstanceEx возвращает S_OK. Если хотя бы один (но не все) из запрошенных интерфейсов недоступен, то CoCreateInstanceEx возвратит CO_S_NOTALLINTERFACES, индицируя частичный успех. Затем вызывающий объект должен исследовать индивидуальные HRESULT в каждой структуре MULTI_QI, чтобы определить, какие интерфейсы были доступны, а какие — нет. Если CoCreateInstanceEx не может создать объект или ни один из запрошенных интерфейсов не доступен, то CoCreateInstanceEx возвращает HRESULT с кодом серьезности ошибки SEVERITY_ERROR, который сообщит, почему произошел отказ в операции.

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

[object,uuid(753A8F7C-A7FF-11d0-8C30-0080C73925BA)] interface IEgghead : IUnknown { import "unknwn.idl"; HRESULT ContemplateNavel(void); }

Имея такое определение интерфейса, клиент может привязать оба типа указателей к новому шимпанзе за одно обращение:

void CreateChimpEatBananaAndThinkAboutIt(void) { // declare and initialize an array of MULTI_QI's // объявляем и инициализируем массив MULTI_QI MULTI_QI rgmqi[2] = { { &IID_IApe, 0, 0 }, { &IID_IEgghead, 0, 0 } }; HRESULT hr = CoCreateInstanceEx( CLSID_Chimp, // make a new chimp - создаем нового шимпанзе 0, // no aggregation - без агрегирования CLSCTX_ALL, // any locality - размещение любое 0, // no explicit host/security info // нет явной информации о хосте и безопасности 2, // asking for two interfaces - запрашиваем 2 интерфейса rgmqi); // array of MULTI_QI structs - массив структур MULTI_QI



if (SUCCEEDED(hr)) { // hr may be CO_S_NOTALLINTERFACES, so check each result // hresult может быть равен CO_S_NOTALLINTERFACES, // поэтому проверяем каждый результат if (hr == S_OK SUCCEEDED(rgmqi[0].hr)) { // it is safe to blindly cast the resultant ptr to the type // that corresponds to the IID used to request the interface // безопасно вслепую преобразовать результирующий // указатель к типу, соответствующему тому IID, // который использовался при запросе интерфейса IАре *рАре = reinterpret_cast<IApe*>(rgmqi[0].pItf); assert(pApe); HRESULT hr2 = pApe->EatBanana(); assert(SUCCEEDED(hr2)); pApe->Release(); } if(hr == S_OK SUCCEEDED(rgmqi[1].hr)) { IEgghead *peh = reinterpret_cast<IEgghead*>(rgmqi[1].pItf); assert(peh); HRESULT hr2 = peh->ContemplateNavel(); assert(SUCCEEDED(hr2)); peh->Release(); } } }

Снова интерфейс и реализация

В предыдущих примерах активации со стороны клиента осуществлялись явные вызовы API-функций СОМ для активации. Часто может понадобиться много шагов для корректной связи с требуемым объектом (например, создать один тип объекта, затем запросить его для ссылки на другой объект, основанный на некоторой информации в запросе). Чтобы избавить клиентов от заботы об алгоритмах по поиску объектов или их созданию, СОМ поддерживает стандартный механизм назначения произвольных имен объектам, на которые они ссылаются. Этот механизм основан на использовании локаторных объектов (locator objects), которые инкапсулируют свой алгоритм связи, скрывая его за стандартным постоянным интерфейсом. Эти локаторы объектов формально называются моникерами и являются просто СОМ-объектами, экспортирующими интерфейс IMoniker. Интерфейс IMoniker является одним из наиболее сложных интерфейсов СОМ; тем не менее, он объявляет один метод, чрезвычайно важный для данной дискуссии, а именно BindToObject:

interface IMoniker : IPersistStream { HRESULT BindToObject([in] IBindCtx *pbc, [in, unique] IMoniker *pmkToLeft, [in] REFIID riid, [out, iid_is(riid)] void **ppv); // remaining methods deleted for clarity // остальные методы удалены для ясности }

Напоминаем, что определения интерфейса являются абстрактными и достаточно неопределенными для того, чтобы допустить множество интерпретаций точной семантики каждого метода. Абстрактную семантику BindToObject можно сформулировать так: "запусти свой алгоритм поиска или создания объекта и возврати типизированный интерфейсный указатель на этот объект, когда он создан или найден". Когда клиент вызывает ВindToObject на моникер, у него нет точных представлений о том, как именно моникер превратит свою внутреннюю структуру в указатель на объект. Имея три различных моникера, можно использовать три совершенно различных алгоритма. Такая полиморфность поведения и делает идиому моникера столь действенной.

Клиенты получают моникеры одним из следующих способов. Клиент может получить моникер от какого-нибудь внешнего агента, такого, как результат вызова метода на некоем уже существующем объекте.
Клиенты могут вызвать явную API-функцию, которая создает моникер определенного типа. Клиенты могут просто иметь строку текста, являющуюся "строкоподобным" состоянием моникера. Последний случай является наиболее интересным, так как он позволяет приложениям загружать и сохранять "имена объектов", используя внешние конфигурационные файлы или системный реестр, в текстовом виде (text-based). Если эта методика открыто документирована как часть конфигурационного состояния приложения, системные администраторы или опытные пользователи смогут переконфигурировать свое приложение, чтобы использовать альтернативную технологию для поиска объектов, которая могла быть или не быть предусмотрена разработчиком исходного приложения. Например, моникер, поддерживающий выравнивание нагрузки, может быть переконфигурирован для проведения иной стратегии выбора хост-машин простым изменением текстовой версии моникера, которая хранится в конфигурационном файле приложения.

Текстовое представление моникера формально называется отображаемым именем (display name). Интерфейс IMoniker объявляет метод GetDisplayName, который позволяет клиентам запрашивать моникер о его отображаемом имени. Более интересная задача — превратить произвольные отображаемые имена в моникеры. Эта задача довольно проблематичная, так как клиент не может просто сказать, какому виду моникера соответствует отображаемое имя. Такую работу выполняет MkParseDisplayName - вероятно, наиболее важная API-функция во всем СОМ.

MkParseDisplayName берет произвольное отображаемое имя и превращает его в моникер:

HRESULT MkParseDisplayName( [in] IBindCtx *pbc, // binding Info - информация о связывании [in, string] const OLECHAR *pwszName, // object name - имя объекта [out] ULONG *pcchEaten, // progress on error - сообщение об ошибке [out] IMoniker **ppmk); // the resultant moniker - результирующий моникер

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


Если префиксы совпадают, то создается новый моникер соответствующего типа и ему присваивается отображаемое имя для дальнейшего анализа. Поскольку моникеры имеют иерархическую структуру и могут быть композитными, то результирующий моникер в действительности может содержать два и более моникеров. Клиент может не заботиться об этой детали реализации. Клиент попросту использует для нахождения искомого объекта результирующий интерфейсный указатель IMoniker, который может указывать, а может не указывать на композитный моникер (composite moniker).

Напомним, что начальная точка входа в класс СОМ проходит через объект этого класса. Чтобы связаться с объектом класса, необходим моникер классового типа (Class Moniker). Это моникеры встроенного типа, предоставляемые моделью СОМ. Классовые моникеры поддерживают CLSID в качестве своего начального состояния и могут быть созданы либо с помощью явной API-функции СОМ CreateClassMoniker.

HRESULT CreateClassMoniker([in] REFCLSID rclsid, [out] IMoniker **ppmk);

либо путем передачи отображаемого имени от Class Moniker в MkParseDisplayName:

clsid:571F1680-CC83-11d0-8C48-0080C73925BA:

Отметим, что префикс "сlsid" является программным идентификатором ProgID для Class Moniker. Следующий код демонстрирует использование МkParseDisplayName для создания Class Moniker, который затем используется для связи с объектом класса Gorilla:

HRESULT GetGorillaClass(IApeClass * &rpgc) { rpgc = 0; // declare the CLSID for Gorilla as a display name // объявляем CLSID как отображаемое имя для Gorilla const OLECHAR pwsz[] = OLESTR("clsid:571F1680-CC83-11d0-8C48-0080C73925BA:"); // create a new binding context for parsing // and binding the moniker // создаем новый связующий контекст // для анализа и связывания моникера IBindCtx *pbc = 0; HRESULT hr = CreateBindCtx(0, &pbc); if (SUCCEEDED(hr)) { ULONG cchEaten; IMoniker *pmk = 0; // ask СОМ to convert the display name to a moniker object // запрашиваем СОМ преобразовать отображаемое имя // в объект моникера hr = MkParseDisplayName(pbc, pwsz, &cchEaten, &pmk); if (SUCCEEDED(hr)) { // ask the moniker to find or create the object that it // refers to // запрашиваем моникер найти или создать объект, // на который моникер ссылается hr = pmk->BindToObject(pbc, 0, IID_IApeClass, (void**)&rpgc); // we now have a pointer to the desired object, so release // the moniker and the binding context // теперь у нас есть указатель на желаемый объект, так что // освобождаем моникер и связующий контекст pmk->Release(); } pbc->Release(); } return hr; }



Связующий контекст, который передается одновременно в MkParseDisplayName и IMoniker::BindToObject, является просто вспомогательным объектом, который позволяет дополнительным параметрам передаваться алгоритмам синтаксического анализа и связывания моникера. В случае нашего простого примера все, что требуется, — это новый связующий контекст в роли заполнителя (placeholder), который запрашивается путем вызова API-функции СОМ CreateBindCtx.

В Windows NT 4.0 введена API-функция, упрощающая вызовы MkParseDisplayName и IMoniker::BindToObject:

HRESULT CoGetObject( [in, string] const OLECHAR *pszName, [in, unique] BIND_OPTS *pBindOptions, [in] REFIID riid, [out, iid_is(riid)] void **ppv);

Эта API-функция реализована следующим образом:

// pseudo-code from OLE32.DLL // псевдокод из OLE32.DLL HRESULT CoGetObject(const OLECHAR *pszName, BIND_OPTS *p0pt, REFIID riid, void **ppv) { // prepare for failure // подготовка на случай сбоя *ppv = 0; // create a bind context // создаем контекст связывания IBindCtx *pbc = 0; HRESULT hr = CreateBindCtx(0, &pbc); if (SUCCEEDED(hr)) { // set bind options if provided // устанавливаем опции связывания, если они требуются if (pOpt) hr = pbc->SetBindOptions(pOpt); if (SUCCEEDED(hr)) { // convert the display name into a moniker // преобразуем отображаемое имя в моникер ULONG cch; IMoniker *pmk = 0; hr = MkParseDisplayName(pbc, pszName, &cch, &pmk); if (SUCCEEDED(hr)) { // ask the moniker to bind to the named object // запрашиваем моникер связаться с именованным объектом hr = pmk->BindToObject(pbc, 0, riid, ppv); pmk->Release(); } } pbc->Release(); } return hr; }

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

HRESULT CreateAGorillaAndEatBanana() { IClassFactory *pcf = 0; // declare the CLSID for Gorilla as a display name // объявляем CLSID как отображаемое имя для Gorilla const OLECHAR pwsz[] = OLESTR("clsid:571F1680-CC83-11d0-8C48-0080C73925BA:"); // find the class object via the gorilla's class moniker // находим объект класса через gorilla's class moniker HRESULT hr = CoGetObject(pwsz, 0, IID_IClassFactory, (void**)&pcf); if (SUCCEEDED(hr)) { IApe *pApe = 0; // use the class object to create a gorilla // используем объект класса для создания gorilla hr = pcf->CreateInstance(0, IID_IApe, (void**)&pApe); if (SUCCEEDED(hr)) { // tell the new gorilla to eat a banana // говорим новой горилле съесть банан hr = pApe->EatBanana(); pApe->Release(); } pcf->Release(); } return hr; }

Снова об интерфейсе и реализации

В предыдущей главе интерфейс СОМ был определен как абстрактный набор операций, выражающий некоторую функциональность, которую может экспортировать объект. Интерфейсы СОМ описаны на языке IDL (Interface Definition Language — язык определений интерфейса) и имеют логические имена, которые указывают на моделируемые ими функциональные возможности. Ниже приведено IDL-определение СОМ-интерфейса IApe:

[object, uuid(753A8A7C-A7FF-11d0-8C30-0080C73925BA)] interface IApe : Unknown { import "unknwn.idl"; HRESULT EatBanana(void); HRESULT SwingFromTree(void); [propget] HRESULT Weight([out, retval] long *plbs); }

Сопровождающая IApe документация должна специфицировать примерную семантику трех операций: EatBanana, SwingFromTree и Weight. Все объекты, раскрывающие IАре посредством QueryInterface, должны гарантировать, что их реализации этих методов придерживаются семантического контракта IАре. В то же время определения интерфейса почти всегда специально оставляют место для интерпретации разработчиком объекта. Это означает, что клиенты никогда не могут быть полностью уверены в точном поведении любого заданного метода, а только в том, что его поведение будет следовать схематическим правилам, описанным в документации к интерфейсу. Эта контролируемая степень неопределенности является фундаментальной характеристикой полиморфизма и одной из основ развития объектно-ориентированного программного обеспечения.

Рассмотрим только что приведенный интерфейс IАре. Вероятно (и даже возможно), что будет более одной реализации интерфейса IАре. Поскольку определение IАре является общим для всех реализаций, то предположения, которые могут сделать клиенты о поведении метода EatBanana, должны быть достаточно неопределенными, чтобы позволить каждой обезьяне — гориллам, шимпанзе и орангутангам (все они могут реализовывать интерфейс IАре), получить свои допустимые (но слегка различные) интерпретации данной операции. Без этой гибкости полиморфизм невозможен.

СОМ определенно трактует интерфейсы, реализации и классы как три различных понятия.
Интерфейсы являются абстрактными протоколами для связи с объектом. Реализации — это конкретные типы данных, поддерживающие один или несколько интерфейсов с помощью точных семантических интерпретаций каждой из абстрактных операций интерфейса. Классы — это именованные реализации, представляющие собой конкретные типы, которым можно приписывать значения, и формально называются СОМ-классами, или коклассами (coclasses).

В смысле инкапсуляции о СОМ-классе известно только его имя и потенциальный список интерфейсов, которые он выставляет. Подобно СОМ-интерфейсам, СОМ-классы именуются с использованием GUID (globally unique identifier — глобально уникальный идентификатор), хотя если GUID используются для именования СОМ-классов, то они называются идентификаторами класса — CLSID. Аналогично именам интерфейсов, эти имена классов должны быть хорошо известны клиенту до того, как он их использует. Поскольку для обеспечения полиморфизма СОМ-интерфейсы являются семантически неопределенными, то СОМ не позволяет клиентам просто запрашивать любую доступную реализацию данного интерфейса. Вместо этого клиенты должны точно специфицировать требуемую реализацию. Это лишний раз подчеркивает тот факт, что СОМ-интерфейсы — это всего лишь абстрактные коммуникационные протоколы, единственное назначение которых — обеспечить клиентам связь с объектами, принадлежащими конкретным, имеющим ясную цель классам реализации .

Кроме того, что реализации могут быть именованы с помощью CLSID, СОМ поддерживает текстовые псевдонимы, так называемые программные идентификаторы (programmatic identifiers), иначе ProgID. Эти ProgID поступают в формате libraryname.classname.version и, в отличие от CLSID, являются уникальными только по соглашению. Клиенты могут преобразовывать ProgID в CLSID и обратно с помощью API-функций СОМ CLSIDFromProgID и ProgIDFromCLSID:

HRESULT CLSIDFromProgID([in, string] const OLECHAR *pwszProgID, [out] CLSID *pclsid); HRESULT ProgIDFromCLSID([in] REFCLSID rclsid, [out, string] OLECHAR **ppwszProgID);



Для преобразования ProgID в CLSID нужно просто вызвать CLSIDFromProgID:

HRESULT GetGorillaCLSID(CLSID& rclsid) { const OLECHAR wszProgID[] = OLESTR("Apes.Gorilla.1"); return CLSIDFromProgID(wszProgID, &rclsid); }

На этапе выполнения будет просматриваться база данных конфигураций СОМ для преобразования ProgID Apes.Gorilla.1 в CLSID, соответствующий классу реализации СОМ.

1

Хотя и мало смысла запрашивать "любую доступную реализацию" данного интерфейса, иногда имеет смысл произвести семантическое группирование реализаций, имеющих определенные общие черты высокого уровня, например, чтобы все они были животными или чтобы все они имели службу регистрации. Чтобы обеспечить обнаружение этого типа компонентов, СОМ поддерживает объявление такой систематики (taxonomy) посредством использования категорий компонентов (component categories). Поскольку часто это тот случай, когда все классы, принадлежащие к одной категории компонентов, будут реализовывать одно и то же множество интерфейсов, то такое условие, без сомнения, является достаточным для принадлежности к одной категории компонентов.

Время жизни сервера

В предыдущих разделах было показано, как СОМ автоматически загружает DLL с целью перенесения реализации объектов в адресное пространство клиентских программ. Однако пока не обсуждалось, как и когда эти DLL выгружаются. Вообще говоря, серверные DLL могут предотвращать преждевременную выгрузку, но именно клиент выбирает момент, когда DLL фактически перестают использоваться. Клиенты, желающие освободить неиспользуемые DLL, вызывают API-функцию СОМ CoFreeUnusedLibraries:

void CoFreeUnusedLibraries(void);

Обычно эта подпрограмма вызывается клиентами в свободное время с целью собрать мусор в своем адресном пространстве. При вызове CoFreeUnusedLibraries СОМ опрашивает каждую из загруженных DLL, чтобы выявить, какие из них не используются. Это делается посредством вызова в каждой DLL функции DllCanUnloadNow, которая должна быть явно экспортирована из этой динамически подключаемой библиотеки.

Функция DllCanUnloadNow, которую экспортирует DLL каждого сервера, должна соответствовать следующей сигнатуре:

HRESULT DllCanUnloadNow(void);

Если DLL желает быть освобожденной, то она возвращает S_OK. Если DLL хочет остаться загруженной, то она возвращает S_FALSE. Серверные DLL должны оставаться загруженными по крайней мере до тех пор, пока сохраняются интерфейсные указатели на ее объекты. Это означает, что в DLL должен быть счетчик всех существующих ссылок на объекты. Чтобы упростить реализацию этого, большинство DLL содержат одну переменную для счетчика блокировок (lock count) и используют две функции для автоматического инкрементирования и декрементирования этого счетчика:

LONG g_cLocks = 0; void LockModule(void) { InterlockedIncrement(&g_cLocks); } void UnlockModule(void) { InterlockedDecrement(&g_cLocks); }

При наличии этих подпрограмм реализация DllCanUnloadNow становится чрезвычайно простой:

STDAPI DllCanUnloadNow(void) { return g_cLocks == 0 ? S_OK : S_FALSE; }

Oстается только вызывать в подходящее время подпрограммы LockModule и UnlockModule.

Существуют две основные причины, которые должны оставлять DLL сервера загруженной: внешние ссылки на экземпляры объектов и объекты класса, а также невыполненные вызовы IClassFactory::LockServer.
Вполне очевидно, как добавить поддержку DllCanUnloadNow в экземпляры и объекты классов. Объекты, расположенные в динамически распределяемой области памяти (такие, как экземпляры классов) просто инкрементируют счетчик блокировок сервера при первом вызове AddRef:

STDMETHODIMP_(ULONG) Chimp::AddRef(void) { if (m_cRef == 0) LockModule(); return InterlockedIncrement(&m_cRef); } и декрементируют счетчик блокировок при заключительном вызове Release:

STDMETHODIMP_(ULONG) Chimp::Release (void) { LONG res = InterlockedDecrement(&m_cRef); if (res == 0) { delete this; UnlockModule(); } return res; }

Поскольку объекты, не размещенные в динамически распределяемой области памяти (такие, как объекты классов), не содержат счетчика ссылок, при каждом вызове AddRef и Release нужно инкрементировать или декрементировать счетчик блокировок:

STDMETHODIMP_(ULONG) ChimpClass::AddRef(void) { LockModule(); return 2; }

STDMETHODIMP_(ULONG) ChimpClass::Release (void) { UnlockModule(); return 1; }

Объекты классов, которые реализуют IClassFactory, должны устанавливать свои серверные счетчики блокировок на вызовы IClassFactory::LockServer:

STDMETHODIMP ChimpClass::LockServer(BOOL bLock) { if (bLock) LockModule(); else UnlockModule(); return S_OK; }

Как будет обсуждаться в главе 6, IClassFactory::LockServer создана в первую очередь для внепроцессных серверов, но она достаточно проста и для использования во внутрипроцессных серверах.

Следует заметить, что в протоколе CoFreeUnusedLibraries/DllCanUnloadNow неотъемлемо присутствует состояние гонки (race condition). Возможно, что один поток задач будет выполнять заключительное освобождение последнего экземпляра, экспортированного из DLL, в то время как второй поток будет выполнять подпрограмму CoFreeUnusedLibraries. В СОМ приняты все меры предосторожности, чтобы избежать этой ситуации. В частности, в реализацию СОМ под Windows NT 4.0 Service Pack 2 добавлена специальная возможность для борьбы с состоянием гонки. Версия Service Pack 2 библиотеки СОМ определяет, чтобы к DLL обращались из нескольких потоков, и вместо того, чтобы незамедлительно выгружать DLL изнутри CoFreeUnusedLibraries, СОМ ставит DLL в очередь DLL, подлежащих освобождению.Затем СОМ будет ждать неопределенное время, пока не разрешит этим неиспользуемым серверным DLL освободиться посредством последующего вызова CoFreeUnusedLibraries, подтверждающего, что никаких остаточных вызовов Release уже не исполняется. Это означает, что в многопоточных средах выгрузка DLL из своего клиента может осуществляться значительно дольше, чем можно ожидать.

1

Вероятно, в Windows NT 5.0 будет предусмотрена дополнительная поддержка для подтверждения того, что DLL освобождаются быстро и безошибочно. Подробности можно найти в документации SDK.

Объекты

class object { public: template <class T> virtual T * dynamic_cast(const type_info& t = typeid(T) ) };

Аноним, 1995

В главе 2 обсуждались основы интерфейсов СОМ вообще и интерфейс IUnknown в частности. Было дано понятие о том, что путем наследования дополнительным интерфейсам объекты могут выставлять более одного вида функциональных возможностей. Был также продемонстрирован механизм, с помощью которого клиенты могут опрашивать объекты, чтобы найти среди них доступные функциональные возможности. Этот механизм — QueryInterface (Интерфейс запросов) — был выделен как версия С++-оператора преобразования типа dynamic_cast, не зависящая от языка программирования и от компилятора.

В предыдущей главе было показано, что QueryInterface можно реализовать непосредственно, используя статические преобразования типа для того, чтобы ограничить область действия указателя this на объект типом интерфейса, который запрашивается клиентом. На физическом уровне этот способ означает просто преобразование идентификаторов интерфейса в объект с помощью соответствующего смещения, то есть способ, который применяется любым компилятором C++ при реализации dynamic_cast.

Хотя реализации QueryInterface из предыдущей главы являются вполне допустимыми для СОМ, правила IUnknown предоставляют разработчику объектов значительно больше гибкости, чем было показано до сих пор. В данной главе эти правила будут исследованы, и продемонстрированы способы реализации, которые из них вытекают.

Динамическая композиция

Если для реализации интерфейса в классе C++ используется множественное наследование или композиция, то в каждом объекте этого класса будут содержаться служебные данные (overhead) указателя vptr размером в четыре байта на каждый поддерживаемый интерфейс (принимая, что sizeof (void*) == 4). Если число интерфейсов, экспортируемых объектом, невелико, то эти служебные данные не играют важной роли, особенно в свете преимуществ, предоставляемых программной моделью СОМ. Если, однако, число поддерживаемых интерфейсов велико, то размер служебных данных vptr может вырасти до такой степени, что часть объекта, не связанная с СОМ, будет казаться маленькой по сравнению с ними. При использовании каждого из этих интерфейсов все время без служебных данных не обойтись. Если же, однако, эти интерфейсы не будут использоваться никогда или использоваться в течение короткого времени, то можно воспользоваться лазейкой в Спецификации СОМ и оптимизировать vptr некоторых неиспользуемых объектов.

Вспомним правило, гласящее, что все запросы QueryInterface на объект относительно IUnknown должны возвращать точно такое же значение указателя. Именно так в СОМ обеспечивается идентификация объектов. В то же время Спецификация СОМ определенно разрешает возвращать другие значения указателей в ответ на запросы QueryInterface относительно любых других типов интерфейсов, кроме IUnknown. Это означает, что для нечасто используемых интерфейсов объект может динамически выделять память для vptr по требованию, не заботясь о возврате того же самого динамически выделенного блока памяти каждый раз, когда запрашивается какой-либо интерфейс. Эта технология временного (transient) размещения композитов впервые была описана в "белой книге" Microsoft Поваренная книга для программистов СОМ (Microsoft white paper The СОМ Programmer's Cookbook), написанной Криспином Госвеллом (Crispin Goswell) (). В этой "белой книге" такие временные интерфейсы называются отделяемыми (tearoff).

Композиция и отделяемые интерфейсы — это две технологии на уровне исходного кода, предназначенные для реализации объектов СОМ на C++. Обе эти технологии требуют, чтобы разработчик объекта имел определения для каждого класса композита или отделяемого интерфейса в исходном коде C++, для возможности обработать подобъект, прежде чем возвратить его посредством QueryInterface. Для ряда ситуаций это очень разумно. В некоторых случаях, однако, было бы удобнее упаковать многократно используемую реализацию одного или большего числа интерфейсов в двоичный компонент, который мог бы обрабатываться через границы DLL, не нуждаясь в исходном коде подкомпонента. Это позволило бы более широкой аудитории повторно использовать подкомпонент, избегая слишком тесной связи с ним, как в случае повторного использования на уровне исходного кода (этот случай описан в главе 1). Однако если компонент повторного использования представляет собой двоичный композит или отделяемый интерфейс, то он должен участвовать в общей идентификации объекта.

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

class Car : public ICar { LONG m_cRef; Car(void) : m_cRef(0) {} STDMETHODIMP QueryInterface(REFIID, void **); STDMETHODIMP_(ULONG) AddRef(void); STDMETHODIMP_(ULONG) Release(void); STDMETHODIMP GetMaxSpeed(long *pn); STDMETHODIMP Brake(void); };

STDMETHODIMP Car::QueryInterface(REFIID riid, void **ppv) { if (riid == IID_IUnknown) *ppv = static_cast<IUnknown*>(this); else if (riid == IID_IVehicle) *ppv = static_cast<IVehicle*>(this); else if (riid == IID_ICar) *ppv = static_cast<ICar*>(this); else return (*ppv = 0), E_NOINTERFACE; ((IUnknown*)*ppv)->AddRef(); return S_OK; }

// car class object's IClassFactory::CreateInstance // интерфейс IClassFactory::CreateInstance // объекта класса car STDMETHODIMP CarClass::CreateInstance(IUnknown *pUnkOuter, REFIID riid, void **ppv) { Car *pCar = new Car; if (*pCar) return (*ppv = 0), E_OUTOFMEMORY; pCar->AddRef(); HRESULT hr = pCar->QueryInterface(riid, ppv); pCar->Release(); return hr; }

Единственность и идентификация

Предыдущий раздел был посвящен запросам QueryInterface, которые представляют собой ответы типа "да/нет" вызывающим объектам. QueryInterface действительно возвращает S_OK (да) или E_NOINTERFACE (нет). Впрочем, когда QueryInterface возвращает S_OK, то он также возвращает объекту интерфейсный указатель. Для СОМ значение этого указателя чрезвычайно важно, так как оно позволяет клиентам определить, действительно ли на один и тот же объект указывают два интерфейсных указателя.

Где мы находимся?

В данной главе обсуждались законы идентификации в СОМ. В этих законах определено, что означает быть объектом СОМ. Законы идентификации СОМ предоставляют разработчику объекта потрясающую гибкость при разделении реализации объекта. В качестве технологии для освобождения подсчета ссылок для каждого интерфейса была представлена композиция. Для сокращения размножения vptr, а также для более эффективного управления состоянием объекта были описаны отделяемые интерфейсы. Затем было показано агрегирование в качестве способа создания одной идентификационной единицы (identity) из двух или более двоичных компонентов. Каждая из этих технологий позволяет более чем одному объекту выступать в качестве одной идентификационной единицы СОМ. Каждая технология имеет свои преимущества, и использование любой из них или всех вместе полностью скрыто от клиентов объекта.

Множественные интерфейсы и имена методов

Множественное наследование является очень эффективной и простой технологией для реализации интерфейсов СОМ в классе C++. Это требует написания очень короткого явного кода, так как большая часть работы компилятора и компоновшика заключается в построении соответствующих СОМ указателей vptr и таблиц vtbl. Если имя метода появляется более чем в одном базовом классе с идентичными типами параметров, то компилятор и компоновщик заполняют каждый элемент vtbl таким образом, чтобы он указывал на одну реализацию метода в классе. Этот режим применяется к таким методам, как QueryInterface, AddRef и Release, так как все интерфейсы СОМ начинаются с этих методов, и все же разработчику класса требуется написать каждый метод только один раз (и это хорошо). Этот же режим применяется и к методам любых интерфейсов, где происходит повтор имени и сигнатуры. Здесь есть одна возможная ловушка множественного наследования.

Иерархия транспортных интерфейсов из этой главы содержит конфликт имен. В интерфейсе ICar (автомобиль) имеется метод, названный GetMaxSpeed (развить максимальную скорость). В интерфейсах IBoat (лодка) и IPlane (самолет) также имеются методы, именуемые GetMaxSpeed с идентичной сигнатурой. Это означает, что при использовании множественного наследования разработчик класса пишет метод GetMaxSpeed один раз, а компилятор и компоновщик инициализируют таблицы vtbl, совместимые с ICar, IBoat и IPlane так, чтобы они указывали только на эту реализацию.

Возможно, это вполне разумное поведение для большого числа реализации. Но что если объекту нужно было вернуть другую максимальную скорость, зависящую от интерфейса, на который был сделан запрос? Поскольку имя и сигнатуры одинаковы, то необходимо принимать неординарные меры для разрешения множественных реализации конфликтного метода. Один из возможных способов состоит в создании промежуточного класса C++, производного от интерфейса и реализующего конфликтный метод путем создания чисто виртуального вызова неконфликтного имени:

struct IXCar : public ICar { // add new non-clashing method as pure virtual // добавляем новый неконфликтный метод как чисто виртуальный virtual HRESULT STDMETHODCALLTYPE GetMaxCarSpeed(long *pval) = 0; // implement clashing method by upcalling // non-clashing implementation in derived class // реализуем конфликтный метод путем вызова // неконфликтной реализации в производном классе STDMETHODIMP GetMaxSpeed(long *pval) { return GetMaxCarSpeed(pval); } };

Объекты имеют статический тип

Один из выводов, который можно сделать из трех требований QueryInterfасе, состоит в том, что множество интерфейсов, поддерживаемых объектом, не может изменяться во времени. Спецификация СОМ четко требует, чтобы этот вывод был верен для всех объектов. Из этого требования следует, что иерархия типов объекта является статичной, несмотря на тот факт, что для определения множества поддерживаемых типов данных клиенты должны опрашивать объекты динамически. Если объект отвечает "да" на запрос интерфейса типа А, то он должен отвечать "да", начиная с этой точки. Если объект отвечает "нет" на запрос интерфейса типа А, то он должен отвечать "нет", начиная с этой точки. Фраза "начиная с этой точки" (from that point on) буквально переводится как "до тех пор, пока есть хотя бы один внешний указатель интерфейса на объект". Обычно это соответствует жизненному циклу базового объекта C++, но язык Спецификации СОМ обладает достаточной свободой, чтобы предоставить разработчикам определенную гибкость (например, иерархия типов глобальной переменной может изменяться, когда все указатели освобождены).

Из того, что все объекты СОМ имеют статическую иерархию типов, следует, что утверждение, записанное в следующем коде, никогда не должно быть ложным, несмотря на то, что идентификатор интерфейса используется в качестве второго параметра:

void AssertStaticType(IUnknown *pUnk, REFIID riid) { IUnknown *pUnk1 = 0, *pUnk2 = 0; HRESULT hr1 = pUnk->QueryInterface(riid, (void**)&pUnk1); HRESULT hr2 = pUnk->QueryInterface(riid, (void**)&pUnk2); // both requests for the same interface should // yield the same yes/no answer // оба запроса того же самого интерфейса // должны получить тот же самый ответ да/нет assert(SUCCEEDED(hr1) == SUCCEEDED(hr2)); if (SUCCEEDED(hr1)) pUnk1->Release(); if (SUCCEEDED(hr2)) pUnk2->Release(); }

Это требование означает, что в СОМ запрещены следующие программные технологии:

Использование временной информации при решении вопроса о том, удовлетворять или нет запрос QueryInterface (например, выдавать интерфейс IMorning (утро) только до 12:00).

QueryInterface и IUnknown

Свойство рефлективности QueryInterface гарантирует, что любой интерфейсный указатель сможет удовлетворить запросы на IUnknown, поскольку все интерфейсные указатели неявно принадлежат к типу IUnknown. Спецификация СОМ имеет немного больше ограничений при описании результатов запросов QueryInterface именно на IUnknown. Объект не только должен отвечать "да" на запрос, он должен также возвращать в ответ на каждый запрос в точности одно и то же значение указателя. Это означает, что в следующем коде оба утверждения всегда должны быть верны:

void AssertSameObject(IUnknown *pUnk) { IUnknown *pUnk1 = 0, *pUnk2 = 0; HRESULT hr1 = pUnk->QueryInterface(IID_IUnknown, (void **)&pUnk1); HRESULT hr2 = pUnk->QueryInterface(IID_IUnknown, (void **)&pUnk2); // QueryInterface(IUnknown) must always succeed // QueryInterface(IUnknown) должно всегда быть успешным assert(SUCCEEDED(hr1) && SUCCEEDED(hr2)); // two requests for IUnknown must always yield the // same pointer values // два запроса на IUnknown должны всегда выдавать // те же самые значения указателя assert(pUnk1 == pUnk2); pUnk1->Release() ; pUnk2->Release() ; }

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

bool IsSameObject(IUnknown *pUnk1, IUnknown *pUnk2) { assert(pUnk1 && pUnk2); bool bResult = true; if (pUnk1 != pUnk2) { HRESULT hr1, hr2; IUnknown *p1 = 0, *p2 = 0; hr1 = pUnk1->QueryInterface(IID_IUnknown, (void **)&p1); assert(SUCCEEDED(hr1)); hr2 = pUnk2->QueryInterface(IID_IUnknown, (void **)&p2); assert(SUCCEEDED(hr2)); // compare the two pointer values, as these // represent the identity of the object // сравниваем значения двух указателей, // так как они идентифицируют объект bResult = (р1 == р2); p1->Release(); p2->Release(); } return bResult; }

В главе 5 будет рассмотрено, что понятие идентификации является фундаментальным принципом, так как он используется в архитектуре удаленного доступа СОМ с целью эффективно представлять интерфейсные указатели на объекты в сети.

QueryInterface рефлективна

Спецификация СОМ требует, чтобы запрос QueryInterface через интерфейсный указатель всегда достигал цели, если запрошенный тип соответствует типу указателя, с помощью которого произведен запрос. Это означает, что

QI(A)->A

всегда должен быть верным.

Это требование проиллюстрировано рис. 4.4 и в следующем фрагменте кода:

void AssertReflexive(ICar *pCar) { if (pCar) { ICar *pCar2 = 0; // request same type of interface // запрос интерфейса того же типа HRESULT hr = pCar->QueryInterface(IID_ICar, (void**)&pCar2); // if the following assertion fails, pCar // did not point to a valid СОМ object // если следующее утверждение неверно, то pCar // не указывает на корректный объект СОМ assert(SUCCEEDED(hr)); pCar2->Release(); } }

Из этого кода следует, что все реализации ICar должны быть способны удовлетворить дополнительные запросы QueryInterface для ICar через интерфейсный указатель ICar. Если бы это не соблюдалось, то было бы невозможно передавать жестко типизированные интерфейсы через параметры базового типа без невосполнимой потери исходного типа:

extern void GetCar(ICar **ppcar); extern void UseVehicle(IVehicle *pv);

ICar *pCar; GetCar(&pCar); UseVehicle(pCar); // ICar-ness is syntactically lost // ICar-ность синтаксически потеряна

void UseVehicle(IVehicle *pv) { ICar *pCar = 0; // try to regain syntactic ICar-ness // пытаемся восстановить синтаксическую ICar-ность HRESULT hr = pv->QueryInterface(IID_ICar, (void**)&pCar); }

Поскольку указатель, использованный в функции UseVehicle, имеет то же самое значение, что и указатель ICar, переданный вызывающим объектом, то выглядело бы неестественным (counterintuitive), если бы этот тип не мог быть восстановлен внутри функции.

Из того, что QueryInterface является симметричным, рефлексивным и транзитивным, следует, что любой интерфейсный указатель на объект должен выдавать тот же самый ответ "да/нет" на данный запрос QueryInterface. Это позволяет клиентам рассматривать иерархию типов объекта как простой граф, все вершины которого непосредственно соединены друг с другом (и с самими собой) с помощью открытых (explicit) ребер. На рис. 4.5 изображен такой граф. Отметим, что в любую вершину графа можно попасть из любой другой вершины, пройдя вдоль только одного ребра.

QueryInterface симметрична

Спецификация СОМ требует, чтобы, если запрос QueryInterface на интерфейс B

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

QI(A)->B

то также должно быть верным

QI(QI(A)->B)->A

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

void AssertSymmetric(ICar *pCar) { if (pCar) { IPlane *pPlane = 0; // request a second type of interface // запрашиваем второй тип интерфейса HRESULT hr = pCar->QueryInterface(IID_IPlane, (void**)&pPlane); if (SUCCEEDED(hr)) { ICar *pCar2 = 0; // request original type of interface // запрашиваем исходный тип интерфейса hr = pPlane->QueryInterface(IID_ICar, (void**)&pCar2); // if the following assertion fails, pCar // did not point to a valid СОМ object // если следующее утверждение не будет правильным, // то pCar не укажет на правильный СОМ-объект assert(SUCCEEDED(hr)); pCar2->Release(); } pPlane->Release(); } }

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

QueryInterface транзитивна

Спецификация СОМ требует также, чтобы, если запрос QueryInterface на интерфейс В удовлетворяется через интерфейсный указатель типа A, а второй запрос QueryInterface на интерфейс C удовлетворяется через указатель типа В, то запрос QueryInterface на интерфейс C через исходный указатель типа A был бы также успешным. Это означает, что если верно

QI(QI(A)->B)->C

то должно быть верным и

QI(A)->C

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

void AssertTransitive(ICar *pCar) { if (pCar) { IPlane *pPlane = 0; // request intermediate type of interface // запрос промежуточного типа интерфейса HRESULT hr = pCar->QueryInterface(IID_IPlane, (void**)&pPlane); if (SUCCEEDED(hr)) { IBoat *pBoat1 = 0; // request terminal type of interface // запрос конечного типа интерфейса hr = pPlane->QueryInterface(IID_IBoat, (void**)&pBoat1); if (SUCCEEDED(hr)) { IBoat *pBoat2 = 0; // request terminal type through the original pointer // запрос конечного типа через исходный указатель hr = pCar->QueryInterface(IID_IBoat, (void**)&pBoat2); // if the following assertion fails, pCar // did not point to a valid СОМ object // если следующее утверждение неверно, то pCar // не указывал на корректный СОМ-объект assert(SUCCEEDED(hr)); pBoat2->Release(); } pBoat1->Release(); } pPlane->Release(); } }

Из транзитивности QueryInterface следует, что все интерфейсы, которые выставляет объект, равноправны и не требуют, чтобы их вызывали в какой-то определенной последовательности. Если бы это было не так, то клиентам пришлось бы заботиться о том, какой указатель на объект использовать для различных запросов QueryInterface. Из транзитивности и симметричности QueryInterface следует, что любой интерфейсный указатель на объект выдаст тот же самый ответ "да/нет" на любой запрос QueryInterface. Единственная ситуация, не охватываемая транзитивностью и симметричностью, это повторные запросы одного и того же интерфейса. Эта ситуация требует, чтобы QueryInterface был и рефлективным.

Снова IUnknown

IUnknown не имеет реализации по умолчанию, которая являлась бы частью интерфейса системного вызова СОМ. Заголовочные файлы SDK не содержат базовых классов, макросов или шаблонов, предусматривающих реализации QueryInterface, AddRef и Release, которые должны использоваться во всех программах на С или C++. Вместо этого Спецификация СОМ (Component Object Model Specification) предоставляет очень точные правила относительно допущений, которые клиенты и объекты могут делать относительно этих трех методов. Этот набор правил формирует протокол IUnknown и позволяет каждому разработчику объекта преобразовать три указанных метода IUnknown во все, что имеет смысл для его или ее объекта.

В главе 2 представлены фактические С++-реализации трех упомянутых методов, но СОМ никоим образом не обязывает объекты использовать их. Все, что требует СОМ, — это чтобы каждая реализация придерживалась базовых правил IUnknown. Как это достигается, не имеет ни малейшего отношения к СОМ. Это делает СОМ совершенно ненавязчивой, так как эта модель не требует, чтобы объект делал системные вызовы, наследовал системным реализациям, а все, что от него требуется, — это объявлять совместимые с СОМ указатели vptr. На самом деле, как будет показано далее в этой главе, можно выставлять наследующие IUnknown указатели vptr из классов, которые не наследуют ни одному интерфейсу СОМ.

Правила IUnknown в совокупности определяют, что значит быть объектом СОМ. Чтобы понять правила IUnknown, полезно начать с конкретного примера. Рассмотрим следующую иерархию интерфейсов:

import "unknwn.idl"; [object, uuid(CD538340-A56D-11d0-8C2F-0080C73925BA)] interface IVehicle : IUnknown { HRESULT GetMaxSpeed([out, retval] long *pMax); }

[object, uuid(CD53834l-A56D-11d0-8C2F-0080C73925BA)] interface ICar : IVehicle { HRESULT Brake(void); }

[object, uuid(CD538342-A56D-11d0-8C2F-0080C73925BA)] interface IPlane : IVehicle { HRESULT TakeOff(void); }

[object, uuid(CD538343-A56D-11d0-8C2F-0080C73925BA)] interface IBoat : IVehicle { HRESULT Sink(void); }

Включение

Не все классы способны к агрегированию. Для того чтобы выставить неагрегируемые классы как часть индивидуальности другого объекта, необходимо, чтобы внешние объекты явно передавали вызовы методов внутренним объектам. Эта технология СОМ часто называется включением (containment).

Как показано на рис. 4.9, включение не требует никакого участия со стороны внутреннего объекта. В то же время требуется, чтобы во внешнем объекте производились реализации каждого интерфейса, выставляемого внутренним объектом. Эти внешние реализации просто передают клиентские запросы внутреннему объекту. Включение СОМ не требует никаких особых забот касательно правил идентификации СОМ, так как внутренний объект никогда не доступен клиенту впрямую и поэтому никогда непосредственно не внедряется в иерархию типов внешнего объекта. Хотя СОМ-включение входит в терминологию СОМ, оно не требует никаких особых программистских ухищрений. Фактически включаемый объект не может обнаружить, что внешний объект переадресовывает запросы его методов от действующего клиента.