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

try

{

if (this->IsAsleep()) return this->DoSnore();

else throw COMException(PUGEPUGNOTASLEEP, IIDIPug, OLESTR(«PugCat»), OLESTR(«I am not asleep!»));

}

catch (COMException& ce)

{

// a C++ COMException was thrown

// было сброшено исключение COMException C++

HRESULT hr = SetErrorInfo(0, ce.mpei);

assert(SUCCEEDED(hr));

ce.mpei->Release();

hrex = ce.mhresult;

}

catch (…)

{

// some unidentified C++ exception was thrown

// было выброшено какое-то неидентифицированное исключение C++

COMException ex(EFAIL, IIDIPug, OLESTR(«PugCat»), OLESTR(«A C++ exception was thrown»));

HRESULT hr = SetErrorInfo(0, ex.mpei);

assert(SUCCEEDED(hr));

ex.mpei->Release();

hrex = ex.mhresult;

}

return hrex;

}

Заметим, что реализация метода заботится о том, чтобы не позволить чисто С++-исключениям переходить через границы метода. Таково безусловное требование СОМ.

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

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

Большая часть этой главы была посвящена IUnknown – базовому интерфейсу, на котором построен весь СОМ. Все интерфейсы СОМ должны наследовать от IUnknown. Следовательно, все объекты СОМ должны реализовывать IUnknown. В IUnknown предусмотрено три сигнатуры метода, посредством которых клиент может безошибочно управлять иерархией типов объекта для доступа к дополнительным возможностям, предоставляемым этим объектом. С учетом этого QueryInterface можно рассматривать как оператор приведения типа в СОМ. По этой же причине IUnknown можно рассматривать как «void *» (указатель на пустой тип) среди указателей интерфейса, так как от него не слишком много пользы до тех пор, пока он не «приведен» (is «cast») к чему-нибудь более содержательному с помощью QueryInterface.

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

Глава 3. Классы

int cGorillas = Gorilla::GetCount();

IApe *pApe = new Gorilla();

pApe->GetYourStinkingPawsOffMeYouDamnDirtyApe();

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

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

В предыдущей главе интерфейс СОМ был определен как абстрактный набор операций, выражающий некоторую функциональность, которую может экспортировать объект. Интерфейсы СОМ описаны на языке 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. Аналогично именам интерфейсов, эти имена классов должны быть хорошо известны клиенту до того, как он их использует. Поскольку для обеспечения полиморфизма СОМ-интерфейсы являются семантически неопределенными, то СОМ не позволяет клиентам просто запрашивать любую доступную реализацию данного интерфейса. Вместо этого клиенты должны точно специфицировать требуемую реализацию. Это лишний раз подчеркивает тот факт, что СОМ-интерфейсы – это всего лишь абстрактные коммуникационные протоколы, единственное назначение которых – обеспечить клиентам связь с объектами, принадлежащими конкретным, имеющим ясную цель классам реализации [1].

Кроме того, что реализации могут быть именованы с помощью 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, соответствующий классу реализации СОМ.

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

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