112

{

void TakeOff(); void Fly(); void Land();

};

interface IFloatPlane : IAirplane

{

void LandingSurface(UINT iSurfaceType); void Float();

void Sink(); void Rust();

void DrainBankAccount();

};

Предположим, что IAirplane уже реализован в компоненте MyAirplane. Внешний компонент может просто включить MyAirplane и использовать его интерфейс IAirplane для реализации членов IAirplane, которые наследует интерфейс IFloatPlane:

void CmyFloatPlane::Fly()

{

m_pIAirplane->Fly();

}

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

void CmyFloatPlane::Land()

{

if (m_iLandingSurface == WATER)

{

WaterLanding();

}

else

{

m_pIAirplane->Land();

}

}

Как видите, использовать включение в данном случае просто. Однако если в интерфейсе IAirplane много членов, то написание кода, передающего вызовы от клиента в MyAirplane, будет утомительным. По счастью, это не вопрос поддержки, так как после обнародования интерфейса он не изменяется. Агрегирование дает некоторую поблажку ленивому программисту, который не хочет реализовывать код для передачи вызовов внутренним объектам. Однако при использовании агрегирования к интерфейсу нельзя добавить свой код. Перейдем теперь к агрегированию.

Реализация агрегирования

Рассмотрим, как работает агрегирование. Клиент запрашивает у внешнего компонента интерфейс IY. Вместо того, чтобы реализовывать IY, внешний компонент запрашивает у внутреннего его интерфейс IY, указатель на который и возвращается клиенту. Когда клиент использует интерфейс IY, он напрямую вызывает функции-члены IY, реализованные внутренним компонентом. В работе клиента с этим интерфейсом внешний компонент не участвует, полный контроль над интерфейсом IY принадлежит внутреннему компоненту.

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

C++ и агрегирование

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

113

Магия QueryInterface

Вот объявление внешнего компонента, который реализует интерфейс IX и предоставляет интерфейс IY посредством агрегирования.

class CA : public IX

{

public:

// IUnknown

virtual HRESULT __stdcall QueryInterface(const IID& iid, void** ppv); virtual ULONG __stdcall AddRef();

virtual ULONG __stdcall Release();

// Интерфейс IX

virtual void __stdcall Fx() { cout << “Fx” << endl; }

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

CA();

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

~CA();

//Функция инициализации, вызываемая фабрикой класса для

//создания включаемого компонента

HRESULT Init();

private:

//Счетчик ссылок long m_cRef;

//Указатель на IUnknown внутреннего компонента

IUnknown* m_pUnknownInner;

};

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

HRESULT __stdcall CA::QueryInterface(const IID& iid, void** ppv)

{

if (iid == IID_IUnknown)

{

*ppv = static_cast<IX*>(this);

}

else if (iid = IID_IX)

{

*ppv = static_cast<IX*>(this);

}

else if (iid = IID_IY)

{

return m_pUnknownInner->QueryInterface(iid, ppv);

}

else

{

*ppv = NULL;

return E_NOINTERFACE;

}

reinterpret_cast<IUnknown*>(*ppv)->AddRef(); return S_OK;

}

В этом примере QueryInterface внешнего компонента просто вызывает QueryInterface внутреннего. Все очень хорошо и просто, но если бы это еще правильно работало!

Проблема заключается не в приведенном коде — она в интерфейсе IUnknown внутреннего компонента. Агрегированный внутренний компонент должен обрабатывать вызовы функций-членов QueryInterface особым образом. Как мы увидим, здесь фактически необходимы две реализации IUnknown.

114

Теперь давайте рассмотрим, почему обычная реализация IUnknown для внутреннего компонента вызывает проблемы. Затем познакомимся с тем, как для их устранения реализуются два интерфейса IUnknown. Я покажу также, как модифицировать создание внутреннего компонента, чтобы оба компонента получили нужные им указатели. Наконец, мы посмотрим, как внешнему компоненту передаются указатели на интерфейсы внутреннего (это более сложный процесс, чем Вам может показаться).

Неверный IUnknown

Задача агрегирования — убедить клиента, что интерфейс, реализованный внутренним компонентом, реализован внешним. Вы должны напрямую передать клиенту указатель на интерфейс внутреннего компонента и внушить ему, что этот указатель принадлежит внешнему компоненту. Если клиенту передать указатель интерфейса, реализованного внутренним компонентом как обычно, то компонент будет представлен клиенту в расщепленном виде. Интерфейс внутреннего компонента использует реализацию QueryInterface внутреннего компонента, тогда как у внешнего компонента имеется своя собственная QueryInterface. Когда клиент прямо запрашивает интерфейсы внутреннего компонента, у него создается иное представление о возможностях компонента, чем если он запрашивает интерфейс у внешнего компонента (рис. 8-4).

Сказанное можно пояснить примером. Предположим, Вы агрегировали компонент. Внешний компонент поддерживает интерфейсы IX и IY. Он реализует IX и агрегирует IY. Внутренний компонент реализует интерфейсы IY и IZ. Создав внешний компонент, мы получаем указатель на его интерфейс IUnknown. С помощью этого интерфейса можно успешно запросить интерфейс IX или IY, но запрос IZ будет всегда возвращать E_NOINTERFACE. Если мы запросим указатель на IY, то получим указатель на интерфейс внутреннего компонента. Если запросить IZ через этот указатель на IY, то запрос будет успешным. Так получается из-за того, что функции интерфейса IUnknown для интерфейса IY реализованы внутренним компонентом. Точно так же, запрос у интерфейса IY интерфейса IX потерпит неудачу, поскольку внутренний компонент не поддерживает IX. Такая ситуация нарушает фундаментальное правило реализации QueryInterface: если Вы можете попасть в определенное место откуда-нибудь, то туда можно попасть откуда угодно.

Виноват здесь интерфейс IUnknown внутреннего компонента. Клиент видит два разных IUnknown, внутренний и внешний. Это сбивает его с толку — каждый из IUnknown реализует QueryInterface по-своему, и каждая QueryInterface поддерживает разные наборы интерфейсов. Клиент должен быть абсолютно независим от реализации компонента-агрегата. Он не должен знать, что внешний компонент агрегирует внутренний, и никогда не должен видеть IUnknown внутреннего компонента. Как было сказано в гл. 3, два интерфейса реализованы одним и тем же компонентом тогда и только тогда, когда оба они возвращают один и тот же указатель в ответ на запрос указателя на IUnknown. Следовательно, необходимо дать клиенту единственный IUnknown и скрыть от него IUnknown внутреннего компонента. Интерфейсы внутреннего компонента должны использовать интерфейс IUnknown, реализованный внешним компонентом. IUnknown внешнего компонента называют внешним IUnknown (outer unknown), или управляющим IUnknown (controlling unknown).

115

Интерфейсы IUnknown для агрегирования

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

Внешний IUnknown

Из гл. 7 Вы помните, что функциям CoCreateInstance и IClassFactory::CreateInstance передается указатель на IUnknown, который мы не использовали:

HRESULT __stdcall CreateInstance(

IUnknown* pUnknownOuter, const IID& iid,

void** ppv

);

Внешний компонент передает указатель на свой интерфейс IUnknown внутреннему компоненту с помощью параметра pUnknownOuter. Если указатель на внешний IUnknown не равен NULL, то компонент агрегируется. Используя указатель на IUnknown, переданный CreateInstance, компонент узнает, агрегируется ли он и кто его агрегирует. Если компонент не агрегируется, он использует собственную реализацию IUnknown. В противном случае он должен делегировать вызовы внешнему IUnknown.

Делегирующий и неделегирующий IUnknown

Для поддержки агрегирования внутренний компонент фактически реализует два интерфейса IUnknown. Неделегирующий (nondelegating) IUnknown реализует IUnknown внутреннего компонента обычным образом. Делегирующий (delegating) IUnknown передает вызовы методов IUnknown либо внешнему IUnknown, либо неделегирующему IUnknown. Если внутренний компонент агрегируется, делегирующий IUnknown передает вызовы внешнему IUnknown, реализованному внешним компонентом. Клиенты агрегата вызывают делегирующий IUnknown, тогда как внешний компонент работает с внутренним через неделегирующий. Эту ситуацию поясняют рисунки: вариант без агрегирования показан на рис. 8-5, вариант с агрегированием — на рис. 8-6.

На рис. 8-6 представлен компонент, агрегирующий IY. В этом случае делегирующий IUnknown вызывает IUnknown, реализованный внешним компонентом. Внешний компонент вызывает неделегирующий IUnknown для управления временем существования внутреннего компонента. Таким образом, когда некоторый компонент вызывает метод IUnknown через указатель на интерфейс IY, он вызывает делегирующий IUnknown, который перенаправляет вызов внешнему IUnknown. В результате внутренний компонент использует реализацию IUnknown внешнего компонента.

Теперь все, что мы должны сделать, — это реализовать делегирующий и неделегирующий IUnknown.

116

Реализация делегирующего и неделегирующего IUnknown

Нам необходимо иметь для компонента две разные реализации IUnknown. Но С++ не позволяет реализовать интерфейс дважды в одном классе. Следовательно, мы изменим имя одного из IUnknown, чтобы избежать конфликта имен. Я выбрал имя InondelegatingUnknown. Вы можете выбрать то, которое Вам больше нравится. Вспомните, что для СОМ имена интерфейсов не имеют значения; СОМ интересуется только структурой vtbl. InondelegatingUnknown объявлен так же, как и IUnknown, за исключением того, что названия этих функцийчленов имеют префикс «Nondelegating».

struct InondelegatingUnknown

{

virtual HRESULT __stdcall NondelegatingQueryInterface(const IID&, void**) = 0; virtual ULONG __stdcall NondelegatingAddRef() = 0;

virtual ULONG __stdcall NondelegatingRelease() = 0;

};

Методы NondelegatingAddRef и NondelegatingRelease интерфейса InondelegatingUnknown реализованы в точности так же, как ранее были реализованы AddRef и Release для IUnknown. Однако в NondelegatingQueryInterface есть небольшое, но очень важное изменение.

HRESULT __stdcall CB::NondelegatingQueryInterface(const IID& iid, void** ppv)

{

if (iid == IID_IUnknown)

{

*ppv = static_cast<INondelegatingUnknown*>(this);

}

else if (iid = IID_IY)

{

*ppv = static_cast<IY*>(this);

}

else

{

*ppv = NULL;

return E_NOINTERFACE;

}

reinterpret_cast<IUnknown*>(*ppv)->AddRef(); return S_OK;

}

Обратите внимание на приведение типа указателя this внутреннего компонента к INondelegatingUnknown. Это приведение очень важно. Преобразуя this к INondelegatingUnknown, мы гарантируем, что будет возвращен неделегирующий IUnknown. Неделегирующий IUnknown всегда возвращает указатель на себя, если у него запрашивается IID_IUnknown. Без этого приведения типа вместо неделегирующего IUnknown возвращался бы делегирующий. Когда компонент агрегируется, делегирующий IUnknown передает все вызовы QueryInterface, Release и AddRef внешнему объекту.