int Fn2();

void Fn3(); char Fn4(); И т.д. void Fn17();

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

Грани - переменные класса

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

В файле Pointee.h class BarFacet { private:

Bar* bar; public:

BarFacet(Bar* b) : bar(b) {}

Интерфейсы к функциям класса Bar

class PointeeGemstone { private:

Pointee* p; public:

operator BarFacet();

И т.д.

В файле Pointee.cpp

class Pointee {

friend class PointeeGemstone;

private:

Bar bar; Внедренная переменная класса Pointee public:

И т.д.

PointeeGemstone::operator BarFacet()

return BarFacet(&p->Bar); Грань переменной

Все прекрасно работает, если вам хватает относительно простых правил согласованности C++. Вероятно, в более общем случае стоит воспользоваться приемами, описанными далее, в разделе «Обеспечение согласованности». В частности, одна из проблем такого упрощенного подхода

заключается в том, что вы можете «перейти» от кристалла к грани BarFacet, но не сможете выполнить обратное преобразование по информации, доступной в грани.

Грани - базовые классы

Грани также могут использоваться для создания эквивалента встроенного преобразования типа от производного класса к базовому.

В файле Pointee.h class FooFacet { private:

Foo* foo; public:

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

Интерфейсы к функциям класса foo

class PointeeGemstone { private:

Pointee* p; public:

operator FooFacet();

И т.д.

В файле Pointee.cpp class Pointee : public Foo { friend class PointeeGemstone; public:

И т.д.

PointeeGemstone::operator FooFacet()

return FooFacet(p); Компилятор преобразует p к Foo*

Как и в случае с гранями-переменными, это может позволить вам многократно использовать одни и те же грани Foo для базовых классов, переменных или отдельных объектов, хотя для обеспечения более строгих правил согласованности, описанных ниже, потребуется более узкая специализация. Например, при таком подходе вы сможете выполнить преобразование от кристалла к грани FooFacet, но не сможете снова вернуться к кристаллу.

Грани - делегаты

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

В файле Pointee.h class BarFacet { private:

Bar* bar;

public:

BarFacet(Bar* b) : bar(b) {}

Интерфейсы к функциям класса Bar

class PointeeGemstone { private:

Pointee* p; public:

operator BarFacet();

И т.д.

В файле Pointee.cpp

class Pointee {

friend class PointeeGemstone;

private:

Bar* bar; Уже не внедренная переменная класса public:

И т.д.

PointeeGemstone::operator BarFacet()

return BarFacet(&p->Bar);

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

Если на вас накатит особенно творческое настроение, можно создать грани, в которых используются комбинации этих четырех подходов. Например, одна грань может включать подмножество интерфейсных функций указываемого объекта; одну интерфейсную функцию, делегирующую переменной класса; другую, делегирующую базовому классу; и третью, работающую с делегатом указываемого объекта. На Капитолийском холме такая ситуация была впервые представлена в Акте о Всестороннем Применении Идиом C++ от 1995 года.

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

Раз вся эта бурная деятельность сконцентрирована вокруг объекта View, то как убрать его подальше от глаз широкой публики? Собственно, это считалось одним из достоинств интерфейсных указателей, не правда ли? Еще раз посмотрите на кристалл вида. Так ли уж необходимо пользователю видеть указываемый объект при использовании этой стратегии? В действительности ему хватит возможности создавать кристаллы, которые, в свою очередь, будут использоваться для получения необходимых граней. Когда это будет сделано, грани и кристаллы можно поместить в файл .h и скрыть указываемый объект в файле .срр.

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