Повторное использование СОМ-объектов
Известно, что основным средством повторного использования существующего кода является наследование реализации (новый класс наследует реализацию операций существующего класса). СОМ не поддерживает это средство. Причина — в типовой СОМ-среде базовые объекты и объекты-наследники создаются, выпускаются и обновляются независимо. В этих условиях изменения базовых объектов могут вызвать непредсказуемые последствия в объектах-наследниках их реализации. СОМ предлагает другие средства повторного использования — включение и агрегирование.
Применяются следующие термины:
q внутренний объект — это базовый объект;
q внешний объект — это объект, повторно использующий услуги внутреннего объекта.
При включении (делегировании) внешний объект является обычным клиентом внутреннего объекта. Как показано на рис. 13.21, когда клиент вызывает операцию внешнего объекта, эта операция, в свою очередь, вызывает операцию внутреннего объекта.
Рис. 13.21. Повторное использование СОМ-объекта с помощью включения
При этом внутренний объект ничего не замечает.
Достоинство включения — простота. Недостаток — низкая эффективность при длинной цепочке «делегирующих» объектов.
Недостаток включения устраняет агрегирование. Оно позволяет внешнему объекту обманывать клиентов — представлять в качестве собственных интерфейсы, реализованные внутренним объектом. Как показано на рис. 13.22, когда клиент запрашивает у внешнего объекта указатель на такой интерфейс, ему возвращается указатель на внутренний, агрегированный интерфейс. Клиент об агрегировании ничего не знает, зато внутренний объект обязательно должен знать о том, что он агрегирован.
Рис. 13.22.Повторное использование СОМ-объекта с помощью агрегирования
Зачем требуется такое знание? В чем причина? Ответ состоит в необходимости особой реализации внутреннего объекта. Она должна обеспечить правильный подсчет ссылок и корректную работу операции Querylnterface.
Представим две практические задачи:
q запрос клиентом у внутреннего объекта (с помощью операции Querylnterface) указателя на интерфейс внешнего объекта;
q изменение клиентом счетчика ссылок внутреннего объекта (с помощью операции AddRef) и информирование об этом внешнего объекта.
Ясно, что при автономном и независимом внутреннем объекте их решить нельзя. В противном же случае решение элементарно — внутренний объект должен отказаться от собственного интерфейса IUnknown и применять только операции IUnknown внешнего объекта. Иными словами, адрес собственного IUnknown должен быть замещен адресом IUnknown агрегирующего объекта. Это указывается при создании внутреннего объекта (за счет добавления адреса как параметра операции CoCreatelnstance или операции IClassFactory::CreateInstance).
Маршалинг
Клиент может содержать прямую ссылку на СОМ-объект только в одном случае — когда СОМ-объект размещен в сервере «в процессе». В случае локального или удаленного сервера, как показано на рис. 13.23, он ссылается на посредника.
Посредник — СОМ-объект, размещенный в клиентском процессе и предоставляющий клиенту те же интерфейсы, что и запрашиваемый объект. Запрос клиентом операции через такую ссылку приводит к исполнению кода посредника.
Посредник принимает параметры, переданные клиентом, и упаковывает их для дальнейшей пересылки. Эта процедура называется маршалингом. Затем посредник (с помощью средства коммуникации) посылает запрос в процесс, который на самом деле реализует СОМ-объект.
Рис. 13.23.Организация маршалинга и демаршалинга
По прибытии в процесс локального сервера запрос передается заглушке. Заглушка распаковывает параметры запроса и вызывает операцию СОМ-объекта. Эта процедура называется демаршалингом. После завершения СОМ-операции результаты возвращаются в обратном направлении.
Код посредника и заглушки автоматически генерируется компилятором MIDL (Microsoft IDL) по IDL-описанию интерфейса.