C++: библиотека программиста

 
177 
class FooClass : public Class { 
public: 
Foo* 
make() 
{ 
Foo* f = new Foo; 
this->SetClass(f); 
return 
f; 
} 
}; 
Выглядит получше, поскольку производные от 
Object
классы и не подозревают об этих фокусах… но 
так ли это? Недостаток этого подхода — в том, что он не работает для экземпляров 
Foo
, объявленных в 
стеке или вложенных в другие классы в виде структур данных. Перед вами одна из ситуаций, в 
которых приходится принимать трудное решение: то ли ограничить класс только динамическими 
экземплярами, то ли искать более сложное решение и без того сложной проблемы. 
Существует еще один вариант — управлять выделением памяти и хранить адеса объекта класса прямо 
над самим объектом в памяти вместо того, чтобы делать его переменной класса предка. Для этого нам 
понадобятся приемы управления памятью, описанные в части 4. 
Внешние структуры данных 
Как упоминалось выше, вы также можете создать глобальную коллекцию с парами экземпляр/
Class
. 
Все не так скверно, как выглядит на первый взгляд, особенно если информация 
Class
нужна только в 
процессе отладки и будет исключена в рабочем режиме. Если соблюдать осторожность в реализации, 
решение также распространяется и на такие вложенные объекты, как стековые переменные или 
экземпляры, хотя для этого вам понадобится соответствующая поддержка со стороны конструктора и 
деструктора основного класса. 
Нестандартные пространства памяти 
Другое решение, рассматриваемое в главах 15 и 16 — физическое разделение объектов по различным 
пространствам памяти в соответствии с их классом. Оно отличается повышенной сложностью и 
попросту не работает для вложенных объектов, но зато обладает впечатляющим быстродействием и 
малым расходом памяти. 
Представители 
В книге «Advanced C++ Programming Styles and Idioms» Джеймс Коплин (James Coplien) выдвинул 
особую разновидность объекта класса, который он назвал представителем (exemplar). Представитель 
— это объект класса, который является экземпляром представляемого им класса. Понятно? У меня от 
таких высказываний голова идет кругом. 
class Exemplar {};
// Символический класс 
class Foo { 
private: 
Foo(); 
// 
И все остальные конструкторы, кроме одного 
public: 
Foo(Exemplar); 
// 
Конструктор представителя 
Foo* 
make(); 
// 
Производящие функции представителя 
}; 
extern Foo* foo; 
// Сам представитель 
Подробности несущественны. Важно то, что один экземпляр (на который ссылается переменная 
foo
) 
выполняет функции объекта класса для класса 
Foo
. В реализациях производящих функций необходимо 
убедиться, что 
this
совпадает с представителем, поскольку производящая функция не должна 
вызываться для всех остальных экземпляров класса. 

---

 178 
С представителями можно делать все то же самое, что и с объектами класса. При этом необходимо 
учитывать следующее: 
• 
Для представителей не нужно создавать отдельный класс 
Class
. 
• 
С представителями не приходится объявлять друзей (обычно объект класса должен быть 
другом того класса, который он представляет). 
• 
Настоящие объекты классов заметно упрощают моделирование иерархий классов. 
• 
Настоящие объекты классов упрощают создание гомоморфного интерфейса для описанных 
выше сведений о классах. 
• 
С объектами классов отличия между тем, что относится к объектам класса/представителям, и 
тем, что относится к реальным экземплярам, становятся более отчетливыми. 
В общем и целом, объекты классов оказываются более гибкими при незначительно усложнении 
реализации по сравнению с экземплярами. 

---

Невидимые 
указатели 
Нетривиальное использование С++ напоминает один известный эпизод из фильма «Сумеречная зона». 
Героиня попадает в автомобильную аварию. Она безуспешно ждет, пока кто-нибудь проедет по дороге, 
и в конце концов решает отправиться за помощью. Но куда бы она ни шла, как бы внимательно ни 
следила за направлением, она всегда возвращалась к обломкам машины. Так и с указателями: куда бы 
вы ни шли, вы все равно вернетесь к обломкам. Хм… пожалуй, мне следовало подыскать более 
оптимистичное сравнение. 
В этой главе мы снова возвращаемся к теме указателей, на этот раз — в свете гомоморфных иерархий 
классов. Рассматриваемые здесь указатели я называю невидимыми (invisible pointers), поскольку в 
большинстве случаев можно устроить так, чтобы клиент абсолютно ничего не знал о присутствии 
указателя между ним и целевым объектом. Джеймс Коплин (James Coplien) рассматривает частный 
случай невидимых указателей и называет его «парадигма конверт/письмо»; мы же поговорим о более 
общем случае. 
Основные концепции 
Если гомоморфизм хорошо подходит для других классов, значит, он подойдет и для указателей. 
Концепция проста: указатель и указываемый объект порождаются от одного и того же чисто 
абстрактного базового класса. 
class Foo { 
public: 
virtual void do_something() = 0; 
virtual void do_something_else() = 0; 
}; 
class PFoo : public Foo { 
private: 
Foo* 
foo; 
public: 
virtual void do_something() { foo->do_something(); } 
virtual void do_something_else() { foo->do_something_else(); } 
}; 
class Bar : public Foo { 
// Все для производного класса 
}; 
Вместо перегрузки оператора 
->
в 
PFoo
используется делегирование. Приведенный фрагмент лишь 
слегка затрагивает данную тему. На практике приходится учитывать множество деталей, начиная с 
того, как скрыть указатели и указываемые объекты от клиентов.