// from wtypes.h (approx.)
// из файла wtypes.h (приблизительно)
#if 0 typedef IID *REFIID;
#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 ) код следующим образом:
Читать дальше