Большой архив статей, книг, документации по программированию, вебдизайну, компьютерной графике, сетям, операционным системам и многому другому
 
<Добавить в Избранное>    <Сделать стартовой>    <Реклама на сайте>    <Контакты>
  Главная Документация Программы Обои   Экспорт RSS E-Books
 
 

   Программирование -> C/C++ -> Сущность технологии COM


Обобщения

В предыдущем примере интерфейс 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;
}

Хотя такое использование вполне допустимо, интерфейс IOleItemContainer был предназначен для работы в тандеме с моникером элемента (Item Moniker), который будет рассматриваться позже в данной главе.

В СОМ определен еще один стандартный интерфейс для создания объектов. Он называется IClassFactory:

// from unknwn.idl из unknwn.idl
[ object, uuid(00000001-0000-0000-C000-000000000046) ]
interface IClassFactory : IUnknown {
  HRESULT CreateInstance( [in] IUnknown *pUnkOuter, 
                          [in] REFIID riid, 
                          [out, iid_is(riid)] void **ppv) ;

  HRESULT LockServer([in] BOOL bLock);
}

Хотя экземпляры класса могли бы экспортировать интерфейс IClassFactory, данный интерфейс обычно экспортируется только объектами класса. Объекты класса не обязаны реализовывать IClassFactory, но, для единообразия, они часто делают это. В момент написания этой книги классы, которые будут встраиваться в среду Microsoft Transaction Server (MTS), должны реализовывать IClassFactory (фактически никакие другие интерфейсы объектов класса не будут распознаваться в MTS).

Интерфейс IClassFactory имеет два метода: LockServer и CreateInstance. Метод LockServer вызывается внутри СОМ во время запроса на внепроцессную активацию и подробно обсуждается в главе 6. Метод CreateInstance используется для запроса на создание объектом класса нового экземпляра класса. Как было в случае IApeClass::CreateApe, тип объекта, который будет подвергаться обработке, определяется объектом класса, которому клиент посылает запрос CreateInstance. Первый параметр CreateInstance используется в агрегировании СОМ и обсуждается в главе 4. Пока же, в рамках третьей главы, для простоты изложения положим этот параметр равным нулю. Второй и третий параметры CreateInstance позволяют методу возвращать клиенту динамически типизируемый указатель интерфейса.

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

HRESULT CreateAGorillaAndEatBanana() 
{
    IClassFactory *pcf = 0;
      // find the class object находим объект класса 
    HRESULT hr = CoGetClassObject(CLSID_Gorilla, CLSCTX_ALL, 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);
          // we're done with the class object, so release it 
          // мы закончили с объектом класса, поэтому освобождаем его
        pcf->Release();
        if (SUCCEEDED(hr)) {
            // tell the new gorilla to eat a banana 
            // приказываем новой горилле есть банан 
            hr = pApe->EatBanana();
            pApe->Release();
        }
    }
    return hr;
}

Этот код является семантически идентичным варианту с функцией, которая использовала интерфейс IApeClass вместо интерфейса IClassFactory.

Для того чтобы предыдущий пример работал корректно, объекту класса Gorilla следует реализовать IClassFactory:

class GorillaClass : public IClassFactory {
  public:
    IMPLEMENT_UNKNOWN_NO_DELETE(GorillaClass) 
    BEGIN_INTERFACE_TABLE(GorillaClass) 
      IMPLEMENTS_INTERFACE(IClassFactory) 
    END_INTERFACE_TABLE() 
    STDMETHODIMP CreateInstance(IUnknown *pUnkOuter,
                                REFIID riid, void **ppv) {
        *ppv = 0;
        if (pUnkOuter != 0)
              // we don't support aggregation yet
              // мы еще не поддерживаем агрегирование
             return CLASS_E_NOAGGREGATION;
              // create a new instance of our C++ class Gorilla
              // создаем новый экземпляр нашего С++-класса Gorilla
        Gorilla *p = new Gorilla;
        if (p == 0)
            return E_OUTOFMEMORY:
              // increment reference count by one
              // увеличиваем счетчик ссылок на единицу
        p->AddRef();
              // store the resultant interface pointer into *ppv
              // записываем результирующий указатель интерфейса в *ppv
        HRESULT hr = p->QueryInterface(riid, ppv);
              // decrement reference count by one, which will delete the
              // object if QI fails
              // уменьшаем на единицу счетчик ссылок,
              // что уничтожит объект при отказе QI
        p->Release();
              // return result of Gorilla::QueryInterface
              // возвращаем результат работы Gorilla::QueryInterface
        return hr;
    } 

    STDMETHODIMP LockServer(BOOL bLock);
};

Реализация LockServer будет обсуждаться в этой главе позже. Отметим, что реализация CreateInstance, в первую очередь, создает новый объект C++ на базе класса Gorilla и запрашивает объект, поддерживает ли он нужный интерфейс. Если объект поддерживает требуемый интерфейс, то вызов QueryInterface инициирует вызов AddRef, и клиент в конечном счете выполнит соответствующий вызов Release. Если же произойдет отказ QueryInterface, то потребуется некоторый механизм для уничтожения созданного нового объекта. Предыдущий пример использует стандартную технологию "заключения в скобки" (bracketing) вызова QueryInterface между парой AddRef/Release. Если произошел сбой вызова QueryInterface, то вызов Release сбросит счетчик ссылок на нуль, запуская тем самым удаление объекта. Если же вызов QueryInterface прошел успешно, то вызов Release установит счетчик ссылок на единицу. Остающаяся ссылка принадлежит клиенту, который и выполнит последний вызов Release, когда объект более не нужен.

Оптимизации
Снова интерфейс и реализация
Моникеры и композиция
Моникеры и сохраняемость
Время жизни сервера
Классы и IDL
Эмуляция классов
Категории компонентов
Где мы находимся?

 

 
Интересное в сети
 
10 новых программ
CodeLobster PHP Edition 3.7.2
WinToFlash 0.7.0008
Free Video to Flash Converter 4.7.24
Total Commander v7.55
aTunes 2.0.1
Process Explorer v12.04
Backup42 v3.0
Predator 2.0.1
FastStone Image Viewer 4.1
Process Lasso 3.70.4
FastStone Image Viewer 4.0
Xion Audio Player 1.0.125
Notepad GNU v.2.2.8.7.7
K-Lite Codec Pack 5.3.0 Full


Наши сервисы
Рассылка новостей. Подпишитесь на рассылку сейчас и вы всегда будете в курсе последних событий в мире информационных технологий.
Новостные информеры. Поставьте наши информеры к себе и у вас на сайте появится дополнительный постоянно обновляемый раздел.
Добавление статей. Если вы являетесь автором статьи или обзора на тему ИТ присылайте материал нам, мы с удовольствием опубликуем его у себя на сайте.
Реклама на сайте. Размещая рекламу у нас, вы получите новых посетителей, которые могут стать вашими клиентами.
 
Это интересно
 

Copyright © CompDoc.Ru
При цитировании и перепечатке ссылка на www.compdoc.ru обязательна. Карта сайта.
 
Rambler's Top100