Всего за 24.5 руб. Купить полную версию
Действительно, разработчики фактически подгоняют коммерческие библиотеки классов под собственные нужды, выпуская «собственную версию», которая лучше приспособлена к данному программному продукту, но уже не является оригинальной библиотекой.
Повторное использование (reuse) кода всегда было одной из классических мотиваций объектного ориентирования. Несмотря на это обстоятельство, написание классов C++,простых для повторного использования, довольно затруднительно. Помимо таких препятствий для повторного использования, как этап проектирования ( design-time ) и этап разработки ( development-time ), которые уже можно считать частью культуры C++, существует и довольно большое число препятствий на этапе выполнения (runtime), что делает объектную модель C++ далекой от идеала для создания программных продуктов повторного использования. Многие из этих препятствий обусловлены моделями компиляции и компоновки, принятой в C++. Данная глава будет посвящена техническим проблемам приведения классов C++ к виду компонентов повторного использования. Все задачи будут решаться методами программирования, которые базируются на готовых общедоступных (off-the-shelf) технологиях. В этой главе будет показано, как, применяя эти технологии, можно создать архитектуру для повторного использования модулей, которая позволяла бы динамично и эффективно строить системы из независимо сконструированных двоичных компонентов.
Распространение программного обеспечения и язык С++
Для понимания проблем, связанных с использованием C++ как набора компонентов, полезно проследить, как распространялись библиотеки C++ в конце 1980-х годов. Представим себе разработчика библиотек, который создал алгоритм поиска подстрок за времяO(1)(то есть время поиска постоянно, а не пропорционально длине строки). Это, как известно, нетривиальная задача. Для того чтобы сделать алгоритм возможно более простым для пользователя, разработчик должен создать класс строк, основанный на алгоритме, который будет быстро передавать текстовые строки (fast text strings) в любую программу клиента. Чтобы сделать это, разработчику необходимо подготовить заголовочный файл, содержащий определение класса:
// faststring.h
class FastString
{
char *mpsz;
public:
FastString(const char *psz);
~FastString(void);
int Length(void) const;
// returns # of characters
// возвращает число символов
int Find(const char *psz) const;
// returns offset
//возвращает смещение
};
После того как класс определен, разработчик должен реализовать его функции-члены в отдельном файле:
// FastString.cpp
#include «faststring.h»
#include
{ strcpy(mpsz, psz); }
FastString::~FastString(void)
{ delete[] mpsz; }
int FastString::Length(void) const
{ return strlen(mpsz); }
int FastString::Find(const char *psz) const
{
//O(1) lookup code deleted for>clarity
1
// код поиска 0(1) удален для ясности
}
Библиотеки C++ традиционно распространялись в форме исходного кода. Ожидалось, что пользователи библиотеки будут добавлять реализации исходных файлов и создаваемую ими систему и перекомпилировать библиотечные исходные файлы на месте, с использованием своего компилятора C++. Если предположить, что библиотека написана на наиболее употребительной версии языка C++, то такой подход был бы вполне работоспособным. Подводным камнем этой схемы было то, что исполняемый код этой библиотеки должен был включаться во все клиентские приложения.
Предположим, что для показанного выше классаFastString сгенерированный машинный код для четырех методов занял 16 Мбайт пространства в результирующем исполняемом файле. Напомним, что при выполнении O(1)-поиска может потребоваться много пространства для кода, чтобы обеспечить заданное время исполнения, – дилемма, которая ограничивает большинство алгоритмов. Как показано на рис. 1.1, если три приложения используют библиотекуFastString , то каждая из трех исполняемых программ будет включать в себя по 16 Мбайт кода.