Производящие |
11 |
|
|
функции и |
|
объекты классов |
|
В предыдущей главе мы стролкнулись с гомоморфными иерархиями классов и с головой погрузились во множественную передачу. В этой главе мы продолжим исследовать царство иерархий классов, рассматривая объекты классов и сопутствующие темы.
Примеры из предыдущей главы обладали одним недостатком — все производные классы были видны клиентам. Но если производные классы погребены в файлах .cpp на глубине нескольких метров, как клиенту создавать экземпляры этих спрятанных классов? Этой теме посвящено начало главы. Производящей функцией (factory function) называется функция, которая инкапсулирует применение оператора new для создания экземпляров класса. Знатоки С++ обычно сходятся на том, что производящие функции — Хорошая Вещь, и вскоре вы поймете почему. Вы оказались на семинаре с коктейлями и хотите найти хорошую тему для разговора? Поднимите стакан и небрежно упомяните о том, как производящие функции выручили вас в трудную минуту.
Во многих программах нам хотелось бы в процессе их выполнения сделать нечто, не поддерживаемое динамической моделью С++ (например, запросить у объекта его класс). Для этой цели существует предложенный стандарт RTTI (Run Time Type Information, Динамическая информация о типе), но по причинам, о которых будет сказано ниже, его вряд ли можно считать универсальным или хотя бы полезным средством. Вместо этого мы рассмотрим нестандартные решения, основанные на концепции объектов классов, в том числе особый случай — представителей классов.
Производящие функции
Предположим, вы согласились, что гомоморфизм — это хорошо, и тут же сотворили свою собственную гомоморфную иерархию классов.
//В файле Grandpa.h class Grandpa { ... };
//Скрыто в файле Grandpa.cpp
class Dad : public Grandpa { ... }; class AuntieEm : public Grandpa { ... };
// Где-то в нашей программе
#include “Grandpa.h”
Grandpa* g = new ... // Стоп! Как создать «папу»?
Допустим, с позиций биологии все понятно, но мы говорим о С++, не правда ли? Проблема заключается в том, что мы надежно изолировали «папу» (Dad) от внешнего мира — по крайней мере для любого кода, расположенного за пределами файла Grandpa.cpp. Замечательный интерфейс
170
Grandpa позволяет нам как угодно манипулировать любым экземпляром производного класса, включая Dad, но при это не существует способа создать этот экземпляр!
make-функции
На сцену выходят производящие функции. По общепринятому соглашению их простейшая форма называется makeFoo(), где Foo — имя генерируемого класса.
class Grandpa { public:
static Grandpa* makeDad(); // Создает экземпляры Dad static Grandpa* makeAuntieEm();
};
// В Grandpa.cpp
Grandpa* Grandpa::makeDad()
{
return new Dad;
}
Grandpa* Grandpa::makeAuntieEm()
{
return new AuntieEm;
}
О существовании конкретных производных классов по-прежнему известно всем, однако настоящие интерфейсы Dad и AuntieEm надежно спрятаны от любопытных глаз.
Символические классы и перегруженные make-функции
Все эти функции makeFoo расходятся с перегружаемой природой С++, не правда ли? Следующий фрагмент помогает выбрать нужную версию make.
class Variation |
Dad {}; |
// Пустое объявление класса |
|
class |
VariationAuntieEm {}; |
|
|
class |
Grandpa { |
|
|
public:
static Grandpa* make(VariationDad); static Grandpa* make(VariationAuntieEm);
}; // В вашей программе
Grandpa* g = Grandpa::make(VariationDad());
Вызов VariationDad() создает анонимный экземпляр (anonymous instance) класса VariationDad —
то есть экземпляр, не связанный ни с какой переменной в исходной области действия. Он живет лишь столько, сколько необходимо для вызова, а затем исчезает. Экземпляр VariationDad нужен лишь для одного — он сообщает компилятору, какая перегруженная версия make должна вызываться. Класс, который не имеет членов и используется подобным образом, называется символическим классом (symbol class). Он играет ту же роль, что и символический тип данных в языках типа Lisp: строка, которая заранее компилируется в более эффективную форму.
Поскольку производные классы все равно инкапсулированы в файле .cpp, мы можем воспользоваться этим обстоятельством и заменить имя исходного Dad другим локальным по отношению к файлу .cpp, а затем просто воспользоваться Dad вместо VariationDad в файле .h.
Оптимизация с применением производящих функций
Задержимся на минутку. Допустим, ни один из производных классов Grandpa не интересует публику настолько, чтобы различать их при выборе производящей функции. Даже в этом случае
171
конструирование экземпляров с помощью одной или нескольких производящих функций вполне оправдано. В частности, при этом скрывается логика выбора производного класса, экземпляр которого создается на основании информации, предоставленной на момент создания. Иначе говоря, производящие функции могут послужить средством оптимизации ваших программ.
class Number { |
|
|
public: |
|
|
static Number* make(); |
// Конструирует число по умолчанию |
|
static Number* make(int); |
|
|
static Number* make(double); |
|
|
static Number* make(string); |
// Например, “-1.23” |
|
}; |
|
|
// В файле .cpp |
|
|
class Integer : public Number { ... }; class Real : public Number { ... };
class ArbitraryPrecisionNumber : public Number { ... };
Number* Number::make()
{
return new Integer(0);
}
Number* Number::make(int x)
{
return new Integer(x);
}
Number* Number::make(double x)
{
return new Real(x);
}
Number* Number::make(string s)
{
// Псевдокод
if (малое целое)
return new Integer(atoi(s)); if (большое целое)
return new ArbitraryPrecisionNumber(s); if (вещественное)
// И т.д.
}
Сделать то же с помощью конструкторов не удастся. К тому моменту, когда компилятор начинает искать конструктор с подходящей сигнатурой, вы уже сообщили ему, экземпляр какого класса создается. Более того, такая методика отделяет структуру производных классов от аргументов производящей функции.
Локализованное использование производящих функций
Одно из самых замечательных применений производящих функций — возможность изолирования кода, изменяемого при переносе программы на другой компьютер или среду. Открытый интерфейс, выраженный средствами базового класса, остается прежним, а в файле .cpp прячется специализированный производный класс с кодом, ориентированным на данную платформу.
class Window { public:
172
static Window* make();
// Далее следует гомоморфный интерфейс
};
// В window.cpp для ОС Windows
class MS_Window : public Window { ... }; Window* Window::make()
{
return MS_Window();
}
// или в window.cpp для Mac OS
class Mac_Window : public Window { ... }; Window* Window::make()
{
return Mac_Window*();
}
Чтобы переключиться с одной платформы на другую, достаточно перекомпилировать и перекомпоновать файл .cpp. Все клиенты класса Window ничего не будут знать о произошедшей локализации (предполагается, что вы собираетесь создать действительно универсальное, гомоморфное представление окна в графическом интерфейсе — задача, перед которой дрогнет даже самый отчаянный проектировщик).
Уничтожающие функции
Уничтожающие функции (junkyard functions) уничтожают экземпляры классов. Идея заключается в том, чтобы сделать деструктор закрытым или защищенным, а затем предоставить функцию, в которой инкапсулируется вызов оператора delete.
class Grandpa { protected:
virtual ~Grandpa(); public:
static Grandpa make();
static void destroy(Grandpa*);
};
// В файле grandpa.cpp
void Grandpa::destroy(Grandpa* g)
{
delete g;
}
Возможно, сейчас это не имеет особого смысла, но в нестандартных схемах управления памятью уничтожающие функции способны принести очень большую пользу. А пока скажите начальнику и коллегам, что уничтожающие функции нужны вам ради симметрии. Они косо посмотрят на вас и отойдут подальше, так что на какое-то время вам будет спокойнее работать.
Снова о двойной передаче: промежуточные базовые классы
Приняв на вооружение производящие функции, мы легко повысим инкапсуляцию двойной передачи.
// В файле grandpa.h
class Grandpa { public:
// Производящие функции и гомоморфный интерфейс