С представителями можно делать все то же самое, что и с объектами класса. При этом необходимо учитывать следующее:

• Для представителей не нужно создавать отдельный класс Class.

• С представителями не приходится объявлять друзей (обычно объект класса должен быть другом того класса, который он представляет).

• Настоящие объекты классов заметно упрощают моделирование иерархий классов.

• Настоящие объекты классов упрощают создание гомоморфного интерфейса для описанных выше сведений о классах.

• С объектами классов отличия между тем, что относится к объектам класса/представителям, и тем, что относится к реальным экземплярам, становятся более отчетливыми.

В общем и целом, объекты классов оказываются более гибкими при незначительно усложнении реализации по сравнению с экземплярами.

Невидимые указатели

Нетривиальное использование С++ напоминает один известный эпизод из фильма «Сумеречная зона». Героиня попадает в автомобильную аварию. Она безуспешно ждет, пока кто-нибудь проедет по дороге, и в конце концов решает отправиться за помощью. Но куда бы она ни шла, как бы внимательно ни следила за направлением, она всегда возвращалась к обломкам машины. Так и с указателями: куда бы вы ни шли, вы все равно вернетесь к обломкам. Хм пожалуй, мне следовало подыскать более оптимистичное сравнение.

В этой главе мы снова возвращаемся к теме указателей, на этот раз - в свете гомоморфных иерархий классов. Рассматриваемые здесь указатели я называю невидимыми (invisible pointers), поскольку в большинстве случаев можно устроить так, чтобы клиент абсолютно ничего не знал о присутствии указателя между ним и целевым объектом. Джеймс Коплин (James Coplien) рассматривает частный случай невидимых указателей и называет его «парадигма конверт/письмо»; мы же поговорим о более общем случае.

Основные концепции

Если гомоморфизм хорошо подходит для других классов, значит, он подойдет и для указателей. Концепция проста: указатель и указываемый объект порождаются от одного и того же чисто абстрактного базового класса.

class Foo { public:

virtual void do something() = 0; virtual void do something e1se() = 0;

class PFoo : public Foo { private:

Foo* foo; public:

virtual void do something() { foo->do something(); }

virtual void do something e1se() { foo->do something e1se(); }

class Bar : public Foo {

Все для производного класса

Вместо перегрузки оператора -> в PFoo используется делегирование. Приведенный фрагмент лишь слегка затрагивает данную тему. На практике приходится учитывать множество деталей, начиная с того, как скрыть указатели и указываемые объекты от клиентов.

Инкапсуляция указателей и указываемых объектов

Одно из величайших преимуществ гомоморфных указателей заключается в том, что указатель вместе с указываемым объектом можно инкапсулировать в файле .cpp. Взгляните на только что приведенный фрагмент. Указатель ничего не добавляет к открытому интерфейсу, представленному в классе Foo, поэтому клиентам не нужно видеть PFoo или производные классы, на которые он ссылается. В сущности, при достаточной аккуратности можно убедить клиентов, что они работают непосредственно с указываемым объектом, хотя на самом деле в качестве центрального звена цепочки присутствует указатель. Отсюда и термин - невидимый указатель.

В файле foo.h class Foo { public:

static Foo* make(); Производящая функция virtual void do something() = 0; virtual void do something e1se() = 0;

В файле foo.cpp

class PFoo : public Foo {

private:

Foo* foo; public:

PFoo(Foo* f) : foo(f) {}

virtual void do something() { foo->do something(); }

virtual void do something e1se() { foo->do something e1se(); }

class Bar : public Foo {

Все для производного класса

Foo* Foo::make()

return new PFoo(new Foo);

Вставить PFoo в существующую программу совсем несложно - при условии, что вы приняли все меры предосторожности, спроектировали его с расчетом на гомоморфную иерархию классов и инкапсулировали производные классы вроде Bar. Ведь вы это сделали, не правда ли? Перед нами очередной мистический принцип - вы делаете что-то не для того, чтобы извлечь непосредственную пользу, а для сохранения мировой гармонии. В один прекрасный день вам потребуется вставить умный указатель, и в гармоничном мире это не вызовет никаких проблем.

Производящие функции

Конечно, производящие функции пригодятся вам каждый раз, когда вы инкапсулируете производные классы. В приведенном выше фрагменте мы изменили производящую функцию так, чтбы она создавала два объекта - указатель и указываемое значение.

Обратите внимание: указываемый объект не создается в конструкторе указателя. Для этого существует веская причина. Вероятно, нам захочется использовать класс указателя PFoo для всех производных классов Foo. Это означает, что некто за пределами класса указателя (производящая функция) решает, что именно следует создать и спрятать в указателе.

В предыдущих главах, посвященных умным указателям, основное внимание уделялось шаблонам и обобщенным классам указателей, соответствующим классам указываемых объектов. С невидимыми указателями шаблоны уже не имеют никакого реального значения.