{

int mcPtrs;

// count of outstanding ptrs

// счетчик невыполненных указателей

public:

// initialize pointer count to zero

// сбросить счетчик указателя в нуль

FastString(const char *psz) : mcPtrs(0) { }

void DuplicatePointer(void)

{

// note duplication of pointer

// отметить дублирование указателя

++mcPtrs;

}

void DestroyPointer(void)

{

// destroy object when last pointer destroyed

// уничтожить объект, когда уничтожен последний указатель

if (-mcPtrs == 0) delete this;

}

: : :

};

Этот совершенно стандартный код мог бы просто быть включен в базовый класс или в макрос С-препроцессора, чтобы его могли использовать все реализации.

Чтобы поддерживать эти методы, все программы, которые манипулируют или управляют указателями интерфейса, должны придерживаться двух простых правил DuplicatePointer/DestroyPointer. Для реализации FastString это означает модификацию двух функций. Функция CreateFastString берет начальный указатель, возвращаемый новым оператором C++, и копирует его в стек для возврата клиенту. Следовательно, необходим вызов DuplicatePointer:

IFastString* CreateFastString(const char *psz)

{

IFastString *pfsResult = new FastString(psz);

if (pfsResult) pfsResult->DuplicatePointer();

return pfsResult;

}

Реализация копирует указатель и в другом месте – в методе Dynamic_Cast:

void *FastString::Dynamic_Cast(const char *pszType)

{

void *pvResult = 0;

if (strcmp(pszType, «IFastString») == 0) pvResult = static_cast(this);

else if (strcmp(pszType, «IPersistentObject») == 0) pvResult = static_cast(this); 

else if (strcmp(pszType, «IExtensibleObject») == 0) pvResult = static_cast(this);

else return 0;

// request for unsupported interface

// запрос на неподдерживаемый интерфейс

// pvResult now contains a duplicated pointer, so

// we must call DuplicatePointer prior to returning

// теперь pvResult содержит скопированный указатель,

// поэтому нужно перед возвратом вызвать DuplicatePointer

((IExtensibleObject*)pvResult)->DuplicatePo1nter();

return pvResult;

}

С этими двумя усовершенствованиями соответствующий код пользователя становится значительно более однородным и прозрачным:

void f(void)

{

IFastString *pfs = 0;

IPersistentObject *ppo = 0;

pfs = CreateFastString(«Feed BOB»);

if (pts) {

рро = (IPersistentObject *) pfs->DynamicCast(«IPersistentObject»);

if (ppo) { ppo->Save(«C:\\autoexec.bat»);

ppo->DestroyPointer(); }

pfs->DestroyPointer(); }

}

Поскольку каждый указатель теперь трактуется как автономный объект с точки зрения времени жизни, клиенту можно не интересоваться тем, какой указатель соответствует какому объекту. Вместо этого клиент просто придерживается двух простых правил и предоставляет объектам самим управлять своим временем жизни. При желании способ вызова DuplicatePointer и DestroyPointer можно легко скрыть за интеллектуальным указателем (smart pointer) C++.

Использование этой схемы вычисления ссылок позволяет объекту весьма единообразно выставлять множественные интерфейсы. Возможность выставления нескольких интерфейсов из одного класса реализации позволяет типу данных участвовать в различных контекстах. Например, новая постоянная подсистема могла бы определить собственный интерфейс для управления автозагрузкой и автозаписью объектов на некоторый специализированный носитель. Класс FastString мог бы добавить поддержку этих возможностей простым наследованием от постоянного интерфейса этой подсистемы. Добавление этой поддержки никак не повлияет на уже установленные базы клиентов, которые, может быть, используют прежний постоянный интерфейс для записи и загрузки строки на диск. Механизм согласования интерфейсов на этапе выполнения может служить краеугольным камнем для построения динамической системы из компонентов, которые могут изменяться со временем.

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

Мы начали эту главу с простого класса C++ и рассмотрели проблемы, связанные с объявлением этого класса как двоичного компонента повторного использования. Первым шагом было употребление этого класса в качестве библиотеки Dynamic Link Library (DLL) для отделения физической упаковки этого класса от упаковок его клиентов. Затем мы использовали понятие интерфейсов и реализации для инкапсуляции элементов реализации типов данных за двоичной защитой, что позволило изменять двоичные представления объектов без необходимости перетрансляции клиентами. Затем, используя для определения интерфейсов подход абстрактного базового класса, эта защита приобрела форму указателя vptr и таблицы vtbl. Далее мы исследовали приемы для динамического выбора различных полиморфных реализаций данного интерфейса на этапе выполнения с использованием LoadLibrary и GetProcAddress. Наконец, мы использовали RTTI-подобную структуру для динамического опроса объекта с целью определить, действительно ли он использует нужный интерфейс. Эта структура предоставила нам методику расширения существующих версий интерфейса, а также возможность выставления нескольких несвязанных интерфейсов из одного объекта.

Короче, мы только что создали модель компонентных объектов (Component Object Model – СОМ).

Глава 2. Интерфейсы

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

Снова об интерфейсах и реализациях

Снова об интерфейсах и реализациях

Цель отделения интерфейса от реализации заключалась в сокрытии от клиента всех деталей внутренней работы объекта. Этот фундаментальный принцип предусматривал уровень косвенности, или изоляции (level of indirection), который позволял изменяться количеству или порядку элементов данных в реализации класса без перекомпиляции клиента. Кроме того, этот принцип позволял клиентам обнаруживать расширенную функциональность путем опроса объекта на этапе выполнения. И, наконец, этот принцип позволяет сделать библиотеку DLL независимой от транслятора C++, который используется клиентом.

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