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

 
101 
заключается в том, что вы можете «перейти» от кристалла к грани 
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; 

---

 102 
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) классов указываемых объектов. Ведущие 
указатели помогают соблюсти некоторые из правил согласованности, о которых будет рассказано 
позже. 

---