Сущность технологии СОМ. Библиотека программиста - [15]

, избавляя клиента от необходимости указывать их символические имена на этапе разработки. Это означает, что методы интерфейса защищены от различий в коррекции символических имен на разных трансляторах. Единственная точка входа, которая явно компонуется по имени, – это CreateFastString – глобальная функция, которая обеспечивает клиенту доступ в мир FastString. Заметим, однако, что эта функция была экспортирована с опцией extern "С", которая подавляет коррекцию символов. Следовательно, все трансляторы C++ ожидают, что импортируемая библиотека и DLL экспортируют один и тот же идентификатор. Полезным результатом этой методики является то, что вы можете спокойно извлечь класс из DLL, использующей одну среду C++, а обратиться к этому классу из любой другой среды C++. Эта возможность необходима при построении основы для независимых от разработчика компонентов повторного пользования.

Полиморфизм на этапе выполнения

Управление реализациями классов с использованием абстрактных базовых классов как интерфейсов открывает целый мир новых возможностей в терминах того, что может случиться на этапе выполнения. Напомним, что DLL FastString экспортирует только один идентификатор – CreateFastString. Теперь пользователю легко динамически загрузить DLL, используя по требованию LoadLibrary, и разрешить этой единственной точке входа использовать GetProcAddress:

IFastString *CallCreateFastString(const char *psz)

{

static IFastString * (*pfn)(const char *) = 0;

if (!pfn) {

// init ptr 1st time through

// первое появление ptr

const TCHAR szDll[] = TEXT(«FastString.DLL»);

const char szFn[] = «CreateFastString»;

HINSTANCE h = LoadLibrary(szDll);

if (h) *(FARPROC*)&pfn = GetProcAddress(h, szFn); }

return pfn ? pfn(psz) : 0;

}

Эта методика имеет несколько возможных приложений. Одна из причин ее использования – предотвращение ошибок, генерируемых операционной системой при работе на машине, где не установлена реализация объектов. Приложения, использующие дополнительные системные компоненты, такие как WinSock или MAPI, используют похожую технику для запуска приложений на машинах с минимальной конфигурацией. Поскольку клиенту никогда не нужно компоновать импортируемую библиотеку DLL, он не зависит от загрузки DLL и может работать на машинах, на которых DLL вообще не установлена. Другой причиной для использования этой методики может быть медленная инициализация адресного пространства. Кроме того, DLL не загружается автоматически во время инициализации; и если в действительности реализация объекта не используется, то DLL не загрузится никогда. Другими преимуществами этого способа являются ускорение запуска клиента и сохранение адресного пространства для длительных процессов, которые могут никогда реально не использовать DLL.

Возможно, одним из наиболее интересных применений этой методики является возможность для клиента динамически выбирать между различными реализациями одного и того же интерфейса. Если описание интерфейса IFastString дано как общедоступное (publicly available), то ничто не препятствует как исходному конструктору (implementor) FastString, так и любым сторонним средствам реализации порождать дополнительные классы реализации от того же самого интерфейса. Подобно исходной реализации класса FastString, эти новые реализации будут иметь такое двоичное представление, что будут совместимы на двоичном уровне с исходным классом интерфейса. Все, что должен сделать пользователь, чтобы добиться полностью совместимых («plug-compatible») реализаций, – это определить правильное имя файла для желаемой реализации DLL.

Чтобы понять, как применить эту методику, предположим, что исходная реализация IFastString выполняла поиск слева направо. Это прекрасно для языков, анализируемых слева направо (например, английский, французский, немецкий). Для языков, анализируемых справа налево, предпочтительней вторая реализация IFastString, осуществляющая поиск справа налево. Эта альтернативная реализация может быть построена как вторая DLL с характерным именем (например, FastStringRL.DLL). Пусть обе DLL установлены на машине конечного пользователя, тогда он может выбрать нужный вариант IFastString простой загрузкой требуемой DLL на этапе выполнения:

IFastString * CallCreateFastString(const char *psz, bool bLeftToRight = true)

{

static IFastString * (*pfnlr)(const char *) = 0;

static IFastString * (*pfnrl)(const char *) = 0;

IFastString *(**ppfn) (const char *) = &pfnlr;

const TCHAR *pszDll = TEXT(«FastString.DLL»);

if (!bLeftToRight) { pszDll = TEXT(«FastStringRL.DLL»);

ppfn = &pfnrl; }

if (!(*ppfn)) {

// init ptr 1st time through

// первое появление ptr

const char szFn[] = «CreateFastString»;

HINSTANCE h = LoadLibrary(pszDll);

if (h) *(FARPROC*)ppfn = GetProcAddress(h, szFn); }

return (*ppfn) ? (*ppfn)(psz) : 0;

}

Когда клиент вызывает функцию без второго параметра,

pfs = CallCreateFastString(«Hi Bob!»);

n = pfs->Find(«ob»);

то загружается исходная DLL FastString, и поиск идет слева направо. Если же клиент указывает, что строка написана на разговорном языке, анализируемом справа налево:

pfs = CallCreateFastString(«Hi Bob!», false);