Читать онлайн «Сущность технологии СОМ. Библиотека программиста». Страница 7

Существует общее решение проблемы версий – переименовывать DLL всякий раз, когда появляется новая версия. Такая стратегия принята в Microsoft Foundation Classes (MFC). Когда номер версии включен в имя файла DLL (например, FastString10.DLL, FastString20.DLL), клиенты всегда загружают ту версию DLL, с которой они были сконфигурированы, независимо от присутствия в системе других версий. К сожалению, со временем, из-за недостаточного опыта в системном конфигурировании, число версий DLL, имеющихся в системе конечного пользователя, может превысить реальное число пользовательских приложений. Чтобы убедиться в этом, достаточно проверить системный каталог любого компьютера, проработавшего больше шести месяцев.

В конечном счете, проблема управления версиями коренится в модели трансляции C++, не рассчитанной на поддержку независимых двоичных компонентов. Требуя знания клиентом двоичного представления объектов, C++ предполагает тесную двоичную связь между клиентом и исполняемыми программами объекта. Обычно такая связь является преимуществом C++, так как она позволяет трансляторам генерировать весьма эффективный код. К сожалению, эта тесная двоичная связь не позволяет переместить реализации класса без проведения клиентом повторной компиляции. По причине этой связи и несовместимости транслятора и компоновщика, упомянутых в предыдущем разделе, простой экспорт определений класса C++ из DLL не обеспечивает приемлемой архитектуры двоичных компонентов.

Концепция инкапсуляции основана на разделении того, как объект выглядит (его интерфейса), и того, как он в действительности работает (его реализации). Проблема в C++ в том, что этот принцип неприменим на двоичном уровне, так как класс C++ одновременно является и интерфейсом, и реализацией. Этот недостаток может быть преодолен, если смоделировать две новые абстракции, являющиеся классами C++, но различающиеся по своей сущности. Если определить один класс C++ как интерфейс для типа данных, а второй – как саму реализацию типа данных, то конструктор объектов теоретически может модифицировать некоторые детали класса реализации, в то время как класс интерфейса останется неизменным. Все, что нужно, – это выдержать соотношение интерфейса с его реализацией так, чтобы не показывать клиенту никаких деталей реализации.

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

// FastStringItf.h

class declspec(dllexport) FastStringItf

{

class FastString;

// introduce name of impl. class

// вводится имя класса реализации

FastString *mpThis;

// opaque pointer (size remains constant)

// непрозрачный указатель (размер остается постоянным)

public: FastStringItf(const char *psz);

~FastStringItf(void);

int Length(void) const;

// returns # of characters

// возвращает число символов

int Find(const char *psz) const;

// returns offset

// возвращает смещение

};

Заметим, что двоичное представление этого класса интерфейса не меняется с добавлением или удалением элементов данных из класса реализации FastString. Кроме того, использование опережающего объявления означает, что определение класса FastString не является необходимым для трансляции этого заголовочного файла. Это эффективно скрывает все детали реализации FastString от транслятора клиента. При использовании этого способа машинный код для методов интерфейса становится единственной точкой входа в DLL объекта, и их двоичные сигнатуры никогда не изменятся. Реализации методов класса интерфейса просто передают вызовы методов действующему классу реализации:

// faststringitf.срр

// (part of DLL, not client)

// (часть DLL, а не клиента)

#include «faststring.h»

#include «faststringitf.h»

FastStringItf::FastStringItf(const char *psz) : mpThis(new FastString(psz))

{ assert(mpThis != 0); }

FastStringItf::~FastStringItf(vo1d)

{ delete mpThis; }

int FastStringItf::Length(void) const

{ return mpThis->Length(); }

int FastStringItf::Find(const char *psz) const

{ return mpThis->Find(psz); }

Эти передающие методы должны быть транслированы как часть DLL FastString, так что когда двоичное представление класса реализации FastString меняется, вызов нового оператора в конструкторе FastStringItf будет сразу же перекомпилирован, если, конечно, зарезервировано достаточно памяти. И опять клиент не получит описания класса реализацииFastString. Это дает разработчику FastString возможность со временем развивать реализацию без прерывания существующих клиентов.

Рисунок 1.4 показывает, как использовать классы-дескрипторы для отделения интерфейса от реализации на этапе выполнения. Заметим, что косвенный подход, введенный классом интерфейса, устанавливает двоичную защитную стену (firewall – брандмауэр) между клиентом и реализацией объекта. Эта двоичная стена очень точно описывает, как клиент может сообщаться с реализацией. Все связи клиент-объект осуществляются через класс интерфейса, который содержит очень простой двоичный протокол для входа в область реализации объекта. Этот протокол не содержит никаких деталей класса реализации в C++.

Хотя методика использования классов-дескрипторов имеет свои преимущества и безусловно приближает нас к возможности безопасного извлечения классов из DLL, она также имеет свои недостатки. Отметим, что класс интерфейса вынужден явно передавать каждый вызов метода классу реализации. Для простого класса вроде FastString только с двумя открытыми операторами, конструктором и деструктором, это не проблема. Для большой библиотеки классов с сотнями или тысячами методов написание этих передающих процедур было бы весьма утомительным и явилось бы потенциальным источником ошибок. Кроме того, для областей с повышенными требованиями к эффективности программ (performance-critical domains), цена двух вызовов для каждого метода (один вызов на интерфейс, один вложенный вызов на реализацию) весьма высока. Наконец, методика классов-дескрипторов не полностью решает проблемы совместимости транслятора/компоновщика, а они все же должны быть решены, если мы хотим иметь основу, действительно пригодную для создания компонентов повторного использования.

Оказывается, применение техники разделения интерфейса и реализации может решить и проблемы совместимости транслятора/компоновщика C++. При этом, однако, определение класса интерфейса должно принять несколько иную форму. Как отмечалось ранее, проблемы совместимости возникают из-за того, что разные трансляторы имеют различные соображения по поводу того, как

1. передавать особенности языка на этапе выполнения;

2. символические имена будут представлены на этапе компоновки.

Если бы кто-нибудь придумал, как скрыть детали реализации транслятора/компоновщика за каким-либо двоичным интерфейсом, это сделало бы написанные на C++ библиотеки DLL значительно более широко используемыми.

Двоичная защита, то есть тот факт, что класс интерфейса C++ не использует языковых конструкций, зависящих от транслятора, решает проблему зависимости от транслятора/компоновщика. Чтобы сделать эту независимость более полной, необходимо в первую очередь определить те аспекты языка, которые имеют одинаковую реализацию в разных трансляторах. Конечно, представление на этапе выполнения таких сложных типов, как С-структуры (structs), может быть выдержано инвариантным по отношению к трансляторам. Это – основное, что должен делать системный интерфейс, основанный на С, и иногда это достигается применением условно транслируемых определений типа прагм (pragmas) или других директив транслятора. Второе, что следует сделать, – это заставить все компиляторы проходить параметры функций в одном и том же порядке (слева направо, справа налево) и зачищать стек также одинаково. Подобно совместимости структур, это также решаемая задача, и для унификации работы со стеком часто используются условные директивы транслятора. В качестве примера можно привести макросы WINAPI/WINBASEAPI из Win32 API. Каждая извлеченная из системных DLL функция определена с помощью этих макросов: