Сущность технологии СОМ. Библиотека программиста
Шрифт:
Dim ursus as Gorilla
Исходя из IDL-определения для Gorilla, данный оператор эквивалентен следующему:
Dim ursus as IApe
поскольку IApe является интерфейсом по умолчанию для класса Gorilla. В любом случае программист мог вызывать методы EatBanana и SwingFromTree с переменной ursus. Если атрибут [default] не указан, то он неявно добавляется к первому
Имея указанное выше библиотечное определение IDL, результирующий заголовочный файл apes.h будет использовать препроцессор С для включения файла apesitfs.h. Этот файл apesitfs.h будет содержать определения абстрактных базовых классов для четырех интерфейсов СОМ IApe, IWarrior, IKeeperOfTheFaith и IEgghead. Кроме того, файл apes.h будет содержать объявления GUID для каждого класса:
extern "С" const CLSID CLSID_Gorilla;
extern "С" const CLSID CLSID_Chimpanzee;
extern "С" const CLSID CLSID_Orangutan;
Соответствующий файл apes_i.с будет содержать определения этих CLSID. Сгенерированная библиотека типов apes.tlb будет содержать описания каждого из интерфейсов и классов, что позволит программисту на Visual Basic написать следующее:
Dim ape As IApe
Dim warrior as IWarrior
Set ape = New Gorilla
' ask СОМ for a new gorilla
' запрашиваем СОМ о новой
gorilla Set warrior = ape
А вот так выглядит Java-версия того же самого кода:
IАре аре;
IWarrior warrior;
аре = new Gorilla;
// no cast needed for [default]
// никаких приведений не требуется для [default] ???
warrior = (IWarrior)ape;
Оба этих фрагмента кода предписывают виртуальной машине использовать CLSID_Gorilla для сообщения CoCreateInstanceEx о том, какой тип объекта нужно создать.
В предыдущем IDL на каждый из интерфейсов IApe, IWarrior, IEgghead и IKeeperOfTheFaith есть ссылки из определения библиотеки. По этой причине их определения присутствуют в генерируемой библиотеке типов, несмотря та то, что они определены вне области действия определения библиотеки. В действительности любые типы данных, используемые как параметры или как базовые интерфейсы для данных интерфейсов, будут в то же время присутствовать в генерируемой библиотеке. Существует хорошая практика – определять оператор с реализацией библиотеки в отдельном IDL-файле, который импортирует все необходимые определения интерфейсов из внешнего IDL-файла, содержащего только описания интерфейсов. Такая практика является обязательной в больших проектах со многими IDL-файлами, так как для IDL-файла, содержащего определение библиотеки, недопустимо импортировать другой IDL-файл, который также содержит определение библиотеки. Путем разделения определений библиотеки по отдельным IDL-файлам можно корректно импортировать интерфейсы, используемые библиотекой, в другие проекты, не беспокоясь о множественных определениях библиотеки. Если не использовать этот способ, то существует только одна возможность импортировать определение интерфейса из IDL-файла, содержащего определение библиотеки, – использовать
// humans.idl
// apeitfs.idl DOESN'T have a library statement, so import
// apeitfs.idl HE ИМЕЕТ оператора library, поэтому импортируем
import «apeitfs.idl»;
[ uuid(753A8AC9-A7FF-11d0-8C30-0080C73925BA), version(1.0), lcld(9), helpstring(«Humans that need apes»)
// «Люди, нуждающиеся в обезьянах»
]
library HumanLib {
importlib(«stdole32.tlb»);
// bring in std defs. – вносим стандартные определения
// Dogs.idl DOES have a library definition, so importlib
// its corresponding type library
// Dogs.idl ИМЕЕТ определение библиотеки, поэтому
// импортируем библиотеку соответствующего типа
importlib(«dogs.tlb»);
[uuid(753A8AD1-A7FF-11d0-8C30-0080C73925BA)]
coclass DogApe {
interface IDog;
interface IApe;
} }
В простых проектах часто используется один IDL-файл, в котором определяются как интерфейсы, так и классы, экспортируемые из проекта. Для простых интерфейсов это имеет смысл, так как генерируемая библиотека типов будет содержать взаимно однозначные образы исходных определений IDL, что позволит пользователям этой библиотеки применять importlib без потери информации. К сожалению, в случае сложных интерфейсов многие из исходных IDL-измов (IDL-ism) теряются в результирующей библиотеке типов, и тогда importlib не будет работать так, как хотелось бы. Грядущая версия компилятора MIDL, быть может, будет способна генерировать библиотеки типов, которые будут содержать все из исходного IDL.
Эмуляция классов
Часто случается, что разработчики классов желают развернуть новые версии уже существующих классов, чтобы исправить дефекты или расширить функциональные возможности. Полезно придать этим новым реализациям новые идентификаторы класса CLSID , чтобы клиенты могли четко различать, какая версия им нужна. В качестве примера посмотрим, что происходит, когда развертывается новая версия класса. Если для идентификации нового класса используется новый CLSID, (например, CLSID_Chimp2), то клиентам, определенно желающим использовать новую версию, следует использовать новый CLSID во время активации: // new client – новый клиент
IАре *рАре = 0; hr = CoCreateInstance(CLSID_Chimp2, 0, CLSCTX_ALL, IID_Ape, (void**)&pApe);
Использование второго CLSID гарантирует, что клиенты не получат случайно старую версию класса Chimp . В то же время старые клиенты делают запросы на активацию с применением старого CLSID:
// old client – старый клиент
IАре *рАре = 0;
hr = CoCreateInstance(CLSID_Chimp, 0, CLSCTX_ALL, IID_Ape, (void**)&pApe);
Чтобы продолжать поддержку старых клиентов, разработчику Chimp необходимо сохранить в реестре исходный CLSID для удовлетворения этих запросов на активацию. Если изменилась семантика класса, то необходимо, чтобы исходный сервер также оставался доступным для этих клиентов. Однако бывает, что семантика просто расширяется. В этом случае предпочтительнее просто переадресовать запросы на активацию от старых клиентов на создание экземпляров нового класса.