Книга могла бы выйти значительно раньше, если бы не Терри Кеннеди (Terry Kennedy) и его друзья из Software AG. Терри был весьма любезен, пригласив меня в Германию помочь им с работой по DCOM/UNIX как раз во время годичного отпуска, который я вырвал специально для написания этой книги. Хотя книга и вышла годом позже из-за того, что я не мог сказать Терри «нет» (это моя вина, а не Терри), но я думаю, что книга получилась несравненно лучше благодаря тому времени, которое я провел за их проектом. В частности, я значительно усилил свою интуицию, работая с Харалдом Стилом (Harald Stiehl), Винни Фролих (Winnie Froehlich), Фолкером Денкхаузом (Volker Denkhaus), Дитмаром Гётнером (Deitmar Gaeitner), Джеффом Ли (Jeff Lee), Дейтером Кеслером (Deiter Kesler), Мартином Кохом (Martin Koch), Блауэром Ауфом (Blauer Aff), Ули Кессом (Uli Kaess), Стивом Уайлдом (Steve Wild) и прославленным Томасом Воглером (Thomas Vogler).
Особые благодарности внимательным читателям, нашедшим ошибки в прежних изданиях этой книги: Тэду Неффу (Ted Neff), Дэну Мойеру (Dan Moyer), Пурушу Рудрекшале (Purush Rudrakshala), Хенгу де Коненгу (Heng de Koneng), Дэйву Хэйлу (Dave Hale), Джорджу Рейли (George Reilly), Стиву Де-Лассусу (Steve DeLassus), Уоррену Янгу (Warren Young), Джеффу Просайзу (Jeff Prosise), Ричарду Граймсу (Richard Grimes), Бэрри Клэвенсу (Barry Klawans), Джеймсу Баумеру (James Bowmer), Стефану Сасу (Stephan Sas), Петеру Заборски (Peter Zaborski), Кристоферу Л. Экерли (Christopher L. Akerley), Роберту Бруксу (Robert Brooks), Джонатану Прайеру (Jonathan Prior), Аллену Чамберсу (Alien Chambers), Тимо Кеттунену (Timo Kettunen), Атулсу Моидекару (Atulx Mohidekar), Крису Хиамсу (Chris Hyams), Максу Рубинштейну (Мах Rubinstein), Брэди Хойзингеру (Bradey Honsinger), Санни Томасу (Sunny Thomas), Гарднеру фон Холту (Gardner von Holt) и Тони Вервилосу (Tony Vervilos).
И, наконец, спасибо Шаху Джехану (Shah Jehan) и корпорации «Coca-Cola» за заправку этой затеи горючим в виде производства соответственно превосходной индийской пищи и доступных безалкогольных напитков.
Дон Бокс
Redondo Beach, CA
Август 1997 года
От издательства
При переводе этой непростой книги о непростой технологии мы попытались сохранить оригинальный авторский стиль, не потеряв при этом ясности изложения. Насколько это удалось, судить читателю.
Редакция выражает особую благодарность Елене Филипповой, руководителю проекта «Королевство Delphi» ( http://delphi.vitpc.com ), и Артему Артемьеву, ведущему программисту фирмы Data Art, за консультации и помощь при выборе книг для издания.
Ваши замечания, предложения, вопросы отправляйте по адресу электронной почты comp@piter.com (издательство «Питер», компьютерная редакция).
Мы будем рады узнать ваше мнение!
Подробную информацию о наших книгах вы найдете на Web-сайте издательства http://www.piter.com .
Все исходные тексты, приведенные в книге, вы найдете по адресу http://www.piter.com/download
Глава 1. СОМ как улучшенный C++
template <class Т, class Ex>
class listt: virtual protected CPrivateAlloc {
list<T**> mlist;
mutable TWnd mwnd;
virtual ~listt(void);
protected:
explicit listt(int nElems, …);
inline operator unsigned int *(void) const
{ return reinterpretcast <int*>(this) ; }
template <class X> void clear(X& rx) const throw(Ex);
};
C++ уже давно с нами. Сообщество программистов на C++ весьма обширно, и большинство из них хорошо знают о западнях и подводных камнях языка. Язык C++ был создан высоко квалифицированной командой разработчиков, которые, работая в Bell Laboratories, выпустили не только первый программный продукт C++ (CFRONT), но и опубликовали много конструктивных работ о C++. Большинство правил языка C++ было опубликовано в конце 1980-х и начале 1990-х годов. В этот период многие разработчики C++ (включая авторов практически каждой значительной книги по C++) работали на рабочих станциях UNIX и создавали довольно монолитные приложения, использующие технологию компиляции и компоновки того времени. Ясно, что среда, в которой работало это поколение программистов, была в основном создана умами всего сообщества C++.
Одной из главных целей языка C++ являлось позволить программистам строить типы, определенные пользователем (user-defined types – UDTs), которые затем можно было бы использовать вне их исходного контекста. Этот принцип лег в основу идеи создания библиотек классов, или структур, какими мы знаем их сегодня. С момента появления C++ рынок библиотек классов C++ расширялся, хотя и довольно медленно. Одной из причин того. что этот рынок рос не так быстро, как можно было ожидать, был NIH-фактор (not invented here – «изобретен не здесь») среди разработчиков C++. Использовать код других разработчиков часто представляется более трудным, чем воспроизведение собственных наработок. Иногда это представление базируется исключительно на высокомерии разработчика. В других случаях сопротивление использованию чужого кода проистекает из неизбежности дополнительного умственного усилия, необходимого для понимания чужой идеологии и стиля программирования. Это особенно верно для библиотек-оберток (wrappers), когда необходимо понять не только технологию того, что упаковано, но и дополнительные абстракции, добавленные самой библиотекой.
Другая проблема: многие библиотеки составлены с расчетом на то, что пользователь будет обращаться к исходному коду данной библиотеки как к эталону. Такое повторное использование «белого ящика» часто приводит к огромному количеству связей между программой клиента и библиотекой классов, что с течением времени усиливает неустойчивость всей программы. Эффект чрезмерной связи ослабляет модульный принцип библиотеки классов и усложняет адаптацию к изменениям в реализации основной библиотеки. Это побуждает пользователей относиться к библиотеке как всего лишь к одной из частей исходного кода проекта, а не как к модулю повторного использования. Действительно, разработчики фактически подгоняют коммерческие библиотеки классов под собственные нужды, выпуская «собственную версию», которая лучше приспособлена к данному программному продукту, но уже не является оригинальной библиотекой.
Повторное использование (reuse) кода всегда было одной из классических мотиваций объектного ориентирования. Несмотря на это обстоятельство, написание классов C++, простых для повторного использования, довольно затруднительно. Помимо таких препятствий для повторного использования, как этап проектирования (design-time) и этап разработки (development-time), которые уже можно считать частью культуры C++, существует и довольно большое число препятствий на этапе выполнения (runtime), что делает объектную модель C++ далекой от идеала для создания программных продуктов повторного использования. Многие из этих препятствий обусловлены моделями компиляции и компоновки, принятой в C++. Данная глава будет посвящена техническим проблемам приведения классов C++ к виду компонентов повторного использования. Все задачи будут решаться методами программирования, которые базируются на готовых общедоступных (off-the-shelf) технологиях. В этой главе будет показано, как, применяя эти технологии, можно создать архитектуру для повторного использования модулей, которая позволяла бы динамично и эффективно строить системы из независимо сконструированных двоичных компонентов.