{
IConnectionPointContainer *pcpc = 0;
HRESULT hr = pUnkObject->QueryInterface(IID_IConnectionPointContainer, (void**)&pcpc);
if (SUCCEEDED(hr)) {
IConnectionPoint *pcp = 0;
hr =pcpc->FindConnectionPoint(IID_IShutdownNotify,&pcp);
if (SUCCEEDED(hr)) {
hr = pcp->Unadvise(dwCookie);
pcp->Release();
}
pcpc->Release();
}
}
Отметим, что в обоих примерах клиент использует метод IConnectionPointContainer::FindConnectionPoint для вызова из объекта его IShutdownNotify-реализации IConnectionPoint. Если объект отклоняет вызов FindConnectionPoint, это говорит о том, что он не понимает семантику интерфейса IShutdownNotify. Это оберегает пользователя от прикрепления произвольных интерфейсов обратного вызова к объекту без полного согласия на это разработчика объекта.
Как и в случае с IUnknown, реализации IConnectionPointContainer и IConnectionPoint в значительной степени типичны. Объекту C++ требуется отдельная единица идентификации СОМ для каждого типа экспортируемого интерфейса, который он предполагает поддерживать. Одна из методик реализации ConnectionPoint состоит в использовании того варианта методики вложения класса/композиции, которая учитывает различия в отношениях тождественности:
class Surfboard : public ISurfboard,
public IHazardousDevice,
public ISharkBait,
public IConnectionPointContainer {
LONG m_cRef; // СОM reference count
// счетчик ссылок СОМ
// Surfboards don't support multiple outbound interfaces
// of a given type, so it simply declares single pointers
// of each possible type of callback interface
// Surfboard не поддерживает несколько экспортируемых
// интерфейсов заданного типа, поэтому он просто
// объявляет одиночные указатели каждого возможного
// типа интерфейса обратного вызова
IShutdownNotify *m_pShutdownNotify;
ISurfboardUser *m_pSurfer;
// to deal with identity relationship of IConnectionPoint,
// define an IShutdownNotify-specific nested class + member
// для работы с отношением тождественности
// IConnectionPoint, определяем специфический для
// IShutdownNotify вложенный класс+член
class XCPShutdownNotify : public IConnectionPoint {
Surfboard *This(void);
// use fixed offset
// испопьзуем постоянное смещение
// IUnknown methods...
// методы IUnknown...
// IConnectionPoint methods...
// методы IConnectionPoint...
} m_xcpShutdownNotify;
// define an ISurfboardUser-specific nested class + member
// определяем специфический для IShutdownNotify вложенный класс+член
class XCPSurfboardUser : public IConnectionPoint {
Surfboard *This(void);
// use fixed offset
// используем постоянное смещение
// IUnknown methods...
// методы IUnknown...
// IConnectionPoint methods...
// методы IConnectionPoint...
} m_xcpSurfboardUser;
// IUnknown methods...
// методы IUnknown...
// ISurfboard methods...
// методы ISurfboard...
// IHazardousDevice methods...
// методы IHazardousDevice...
// ISharkBait methods...
// методы ISharkBait...
// IConnectionPointContainer methods...
// методы IConnectionPointContainer...
};
Следует указать, что экземпляры класса Surfboard будут иметь две отдельные реализации IConnectionPoint, одна из которых используется для присоединения интерфейсов обратного вызова IShutdownNotify, а вторая – для присоединения интерфейсов ISurfboardUser. Эти две реализации разделены на отдельные классы C++, что позволяет каждой реализации IConnectionPoint иметь свои собственные уникальные реализации IUnknown и IConnectionPoint. В частности, может иметься три отдельных реализации QueryInterface со своими собственными наборами интерфейсных указателей, которые могут быть выделены для создания трех отдельных СОМ-копий.
Из приведенного выше определения класса следует такая QueryInterface-peaлизация основного класса Surfboard:
STDMETHODIMP Surfboard::QueryInterface(REFIID riid, void**ppv)
{
if (riid == IID_IUnknown || riid == IID_ISurfboard)
*ppv = static_cast<ISurfboard*>(this);
else if (riid == IID_IHazardousDevice)
*ppv = static_cast< IHazardousDevice *>(this);
else if (riid == IID_ISharkBait)
*ppv = static_cast<ISharkBait *>(this);
else if (riid == IID_IConnectionPointContainer)
*ppv = static_cast<IConnectionPointContainer *>(this);
else
return (*ppv = 0), E_NOINTERFACE;
((IUnknown*)*ppv)->AddRef();
return S_OK;
}
Отметим, что доступ к интерфейсу IConnectionPoint не может быть осуществлен через эту главную реализацию QueryInterface. Каждый из методов QueryInterface вложенного класса будет выглядеть примерно так:
STDMETHODIMP Surfboard::XCPShutdownNotify::QueryInterface(REFIID riid, void**ppv)
{
if (riid == IID_IUnknown || riid == IID_IConnectionPoint)
*ppv = static_cast<IConnectionPoint *>(this);
else
return (*ppv = 0), E_NOINTERFACE;
((IUnknown*)*ppv)->AddRef();
return S_OK;
}
Эту же реализацию можно было бы применить и к классу XCPSurfboardUser. Между объектом Surfboard и двумя подобъектами, которые реализуют интерфейс IConnectionPoint не существует идентичности.
Для того чтобы объект Surfboard не уничтожил себя раньше времени, подобъекты администратора соединений просто делегируют вызовы своих методов AddRef и Release в содержащий их объект surfboard:
STDMETHODIMP_(ULONG) Surfboard::XCPShutdownNotify::AddRef(void)
{
return This()->AddRef();
/* AddRef containing object */
/* AddRef объекта-контейнера */
}
STDMETHODIMP_(ULONG) Surfboard::XCPShutdownNotify::Release(void)
{
return This()->Release();
/* Release containing object */
/* Release объекта-контейнера */
}
В приведенных выше методах предполагается, что метод This возвращает указатель на объект-контейнер Surfboard, используя вычисление некоторого постоянного смещения.
Клиенты находят интерфейсы объекта IConnectionPoint посредством вызова метода объекта FindConnectionPoint, который для класса Surfboard мог бы выглядеть примерно так:
STDMETHODIMP Surfboard::FindConnectionPoint(REFIID riid, IConnectionPoint **ppcp)
{
if (riid == IID_IShutdownNotify)
*ppcp = IID_IShutdownNotify;
else if (riid == IID_ISurfboardUser)
*ppcp = &m_xcpSurfboardUser;
else
return (*ppcp = 0), CONNECT_E_NOCONNECTION;
(*ppcp)->AddRef();
return S_OK;
}
Отметим, что объект выдает интерфейсные указатели IConnectionPoint только при запросе тех интерфейсов, на которые он сможет сделать обратный запрос. Необходимо указать также на поразительное сходство с большинством реализации QueryInterface. Основное различие состоит в том, что QueryInterface имеет дело с импортируемыми (inbound) интерфейсами, в то время как FindConnectionPoint – с экспортируемыми (outbound) интерфейсами.
Поскольку метод IConnectionPoint::Advise принимает только интерфейс IUnknown, статически типизированный как интерфейсный указатель обратного вызова[1], то реализации Advise должны использовать QueryInterface для того, чтобы привязать указатель обратного вызова к соответствующему типу интерфейса:
STDMETHODIMP Surfboard::XCPShutdownNotify::Advise(IUnknown *pUnk, DWORD *pdwCookie)
{
assert (pdwCookie && pUnk);
*pdwCookie = 0;
if (This()->m_pShutdownNotify) // already have one
// уже имеем один
return CONNECT_E_ADVISELIMIT;
// QueryInterface for correct callback type
// QueryInterface для корректирования типа обратного вызова
HRESULT hr = pUnk->QueryInterface(IID_IShutdownNotify,
(void**)&(This()->m_pShutdownNotify));
if (hr == E_NOINTERFACE)
hr = CONNECT_E_NOCONNECTION;
if (SUCCEEDED(hr)) // make up a meaningful cookie
// готовим значимый маркер
*pdwCookie = DWORD(This()->m_pShutdownNotify);
return hr;
}
Напомним, что QueryInterface неявно вызывает AddRef, что означает следующее: объект Surfboard теперь хранит ссылку обратного вызова, причем она остается легальной за пределами области действия метода Advise. Отметим также, что если объект обратного вызова не реализует соответствующий интерфейс, то результирующий HRESULT преобразуется в CONNECT_E_NOCONNECTION. Если же сбой QueryInterface последовал по какой-либо иной причине, то HRESULT от QueryInterface передается вызывающей программе[2].
Основанный на приведенной выше реализации Advise соответствующий метод Unadvise имеет следующий вид:
STDMETHODIMP Surfboard::XCPShutdownNotify::Unadvise(DWORD dwCookie)
{
// ensure that the cookie corresponds to a valid connection
1 В этом заключается один из известных дефектов в схеме точек стыковки. Другой хорошо известный дефект состоит в том, для каждого типа интерфейса обратного вызова требуется явный вызов FindConnectionPoint. Оба этих дефекта отрицательно сказываются на производительности с связи в увеличением числа полных обходов, которые вносит каждый из этих дефектов. Влияние использования точек стыковки на производительность служит напоминанием, что интерфейсы следует разрабатывать, имея в виду возможный межапартаментиыи доступ.
2 Распространенная ошибка, которая может привести к отказу в доступе, состоит в том, что объект пытается вступить в контакт с процессом объекта обратного вызова, так как контроль доступа вызывающей программы не разрешает вызовы из принципала зашиты объекта.