#endif

#ifdef _cplusplus

#define REFIID const IID&

#else

#define REFIID const IID * const

#endif

Этот несколько гротескный прием необходим, поскольку многие базовые интерфейсы СОМ были определены без учета возможного применения IDL.

Асинхронные методы

Вызовы методов в СОМ являются по умолчанию синхронными. Это означает, что клиентский поток заблокирован до тех пор, пока ответное ORPC-сообщение не получено и не демаршалировано. Такая схема в полной мере демонстрирует, как работает обычный вызов метода в одном потоке (same-thread), и это с полным основанием принято по умолчанию. До появления Windows NT 5.0 не было способа осуществить вызов метода и продолжать обработку одновременно с выполнением метода без явного порождения дополнительных потоков. В версии СОМ Windows NT 5.0 вводится поддержка асинхронного вызова метода. Асинхронность является свойством метода и должна быть выражена в IDL посредством применения атрибута [async_uuid].

Детали этой технологии во время написания данного текста находились в процессе непрерывного изменения. За подробностями обращайтесь к соответствующей документации.

Где мы находимся?

В данной главе обсуждался ряд тем, относящихся к разработке и использованию интерфейсов СОМ. Хотя эта глава никоим образом не содержит исчерпывающего каталога полезных идиом разработки, в ней была сделана попытка решить несколько существенных вопросов, не обсуждавшихся в предшествующих главах книги. По мере того как мое собственное понимание СОМ развивалось в течение двух лет, потребовавшихся для написания этой книги, я пришел к убеждению, что разработчикам следовало бы уделять меньше внимания специфическим возможностям СОМ (таким, как точки стыковки, моникеры, диспетчерские интерфейсы), а вместо этого сосредоточиться на трех китах СОМ: интерфейсы, объекты классов, апартаменты. Вооруженный доскональным пониманием этих трех тем, я твердо верю, что нет вершин, которые нельзя было бы покорить с помощью СОМ.

Проиложение А. Эволюция объектов

Сокращенную версию этого очерка предполагается опубликовать в январском, 1998 года, выпуске Microsoft Systems Journal. Здесь этот очерк включен в приложение, поскольку в нем СОМ рассматривается в исторической перспективе.

Развитие объектно-ориентированного программирования перешло в стадию коммерческого применения в конце 1980-х годов. Центральной темой объектного ориентирования в середине 1980-х было использование классов, которые позволили разработчикам моделировать состояние и поведение как единый абстрактный модуль. Такая упаковка состояния и поведения помогает провести в жизнь модульный принцип через применение инкапсуляции. В классическом объектном ориентировании объекты принадлежали классам, а клиенты манипулировали объектами посредством основанных на классах ссылок. Такая модель программирования принята в большинстве сред и библиотек C++ и Smalltalk тех времен. В то время программисты, придерживающиеся строгого стиля, могли извлечь максимальную пользу из классового подхода, составляя программы на языках, широко применяющих процедуры. Однако действительно широкое распространение объектно-ориентированного программирования наступило только тогда, когда объектное ориентирование стало явно поддерживаться разработчиками языков программирования и сервисных программ. К числу программных сред, сыгравших важнейшую роль в обеспечении успеха объектного ориентирования, относятся оболочка МасАрр фирмы Apple на базе Object Pascal, первые среды SmallTalk фирм ParePlace и Digitalk, а также Turbo C++ фирмы Borland.

Одним из ключевых преимуществ использования среды разработки, явно поддерживающей объектное ориентирование, была возможность применения полиморфизма для интерпретации групп сходных объектов как совместимых друг с другом по типу. С целью поддержки полиморфизма в объектном ориентировании были введены понятия наследования и динамического связывания, что позволило явно группировать сходные объекты в коллекции (collections) связанных абстракций. Рассмотрим следующую простейшую иерархию классов C++:

class Dog {

public:

virtual void Bark(void);

};

class Pug : public Dog {

public:

virtual void Bark(void);

};

class Collie : public Dog {

public:

virtual void Bark(void);

};

Поскольку классы Collie и Pug оба совместимы по типу с классом Dog , то клиенты могут написать групповой (generic ) код следующим образом:

void BarkLikeADog(Dog& rdog) {

rdog.Bark();

}

Поскольку метод Bark является виртуальным и динамически связанным, механизмы диспетчеризации методов C++ обеспечивают выполнение нужного кода. Это означает, что функция BarkLikeADog не полагается на точный тип объекта, на который она ссылается; ей достаточно, чтобы это был тип, совместимый с Dog. Данный пример может быть легко переделан для любого числа языков, поддерживающих объектно-ориентированное программирование.

Приведенная иерархия классов является типичным примером тех приемов, которые применялись во время первой волны развития объектного ориентирования. Одной из основных характеристик этой первой волны было наследование реализаций. Наследование реализаций является мощным приемом программирования, если применять его строго по правилам. Однако при его неправильном применении результирующая иерархия типов может стать образцом чрезмерной связи между базовым и производным классами. Типичным недостатком такой связи является то, что зачастую неясно, должна реализация метода базовым классом вызываться из версии порожденного класса или нет. Для примера рассмотрим реализацию Bark класса Pug :

void Pug::Bark(void) {

this->BreathIn();

this->ConstrictVocalChords();

this->BreathOut(); }

Что произойдет, если реализация Bark основным классом Dog не вызвана, как в случае приведенного выше фрагмента кода? Возможно, метод базового класса записывает для дальнейшего использования, сколько раз лает (barks) конкретная собака (dog)? Если это так, то класс Pug вторгся в соответствующую часть реализации базового класса Dog. Для правильного применения наследования реализаций необходимо нетривиальное количество внутреннего знания для обеспечения сохранности базового класса. Это количество детального знания превышает уровень, требующийся для того, чтобы просто быть клиентом базового класса. По этой причине наследование реализации часто рассматривается как повторное использование белого ящика.

Один из подходов к объектному ориентированию, сокращающий чрезмерную связь систем типов, но сохраняющий преимущества полиморфизма, заключается в том, чтобы наследовать только сигнатуры типов, но не код реализации. Это является фундаментальным принципом разработок на базе интерфейса, что можно рассматривать как вторую волну объектного ориентирования. Программирование на базе интерфейса является усовершенствованием классического объектного ориентирования, которое считает, что наследование является прежде всего механизмом для выражения отношений между типами, а не между иерархиями реализаций. В основе интерфейсно-ориентированных разработок лежит принцип отделения интерфейса от реализации. В этом направлении интерфейсы и реализации являются двумя различными понятиями. Интерфейсы моделируют абстрактные требования, которые могут предъявляться к объекту. Реализации моделируют конкретные обрабатываемые типы, которые могут поддерживать один или более интерфейсов. Многие из этих преимуществ интерфейсно-ориентированного развития могли быть достигнуты и традиционными средствами первой волны в рамках строгого стиля программирования. Однако широкое принятие этого направления произошло только тогда, когда была получена явная поддержка со стороны разработчиков языков и инструментальных средств программного обеспечения. В число программных сред, сыгравших главную роль в обеспечении успеха интерфейсно-ориентированного развития, входят модель компонентных объектов (Component Object Model – СОМ) фирмы Microsoft, программная среда Orbix Object Request Broker фирмы Iona и Digitalk, а также явная поддержка интерфейсно-ориентированной разработки в рамках языка Java.