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

Проверка граней

Давайте еще немного расширим эту идиому и предположим, что некоторая грань может поддерживаться или не поддерживаться объектом. О том, почему и как это может произойти, мы поговорим во время изучения переходных типов далее в этой главе, а пока ответим на вопрос: как клиент может определить, поддерживается ли некоторый объект некоторой гранью? Решение построено на другом С++-изме - перегрузке оператора ! .

class ViewEvents { private:

View* view; public:

ViewEvents(View* v) : view(v) {}

bool operator!() { return view == NULL; }

И т.д.

В клиентском коде ViewEvents ve(aViewGemstone); if (!ve) {

cerr << Вид не обрабатывает событий! << endl; throw interface error;

Предполагается, что aViewGemstone относится к кристаллам вида, о которых говорилось выше, и содержит операторную функцию operator ViewEvents(). Ключевая строка ViewEvents ve(aViewGenistone) работает в два этапа: сначала вызывается операторная функция operator ViewEvents(), выполняющая преобразование, а затем ve конструируется с помощью конструктора копий ViewEvents. Если кристалл вида решает, что данный вид не обрабатывает событий, он может сконструировать экземпляр ViewEvents с view, равным NULL. Затем оператор ! проверяет возвращенную грань. Функции грани также могут проверять наличие объекта перед тем, как пытаться что-то делегировать ему.

Void ViewEvents::DoSomething()

if (!*this) то есть if (view == NULL)

Инициировать исключение view->DoSomething();

Обеспечение согласованности

В одних отношениях C++ непроницаем, как гранитная скала, в других - дыряв, как решето. Одна из таких дыр - несогласованный подход к преобразованию типов. Вы можете получить адрес переменной класса, но по этому адресу нельзя безопасно перейти к объекту, которому принадлежит переменная. У компилятора хватает ума для автоматического приведения указателя на производный класс к указателю на базовый, но вернуться к указателю на производный класс он уже не сможет. Придется выполнять небезопасное явное преобразование, пользующееся дурной славой. Большинство программистов и проектировщиков лишь испускает глубокий вздох, обычно приберегаемый для супружеских ссор, и живет с этими несоответствиями. Однако благодаря идиоме граней открывается уникальная возможность исправить этот аспект C++. Существуют три свойства, которые в совокупности обеспечивают отсутствующую в C++ степень согласованности. В следующем описании выражение а=>b означает, что грани типа А содержат оператор преобразования, дающий грань типа B; а и b являются конкретными экземплярами типов А и В соответственно. Хотя эти правила относятся к специфике C++ и граней, они также являются частью стандартной дисциплины проектирования, используемой в технологии СОМ компании Microsoft:

1. Симметричность. Если а=>Ь, то Ь=>а. Последствия: грань - переменная класса должна уметь восстанавливать вмещающий объект, из которого она получена, а грань - базовый класс должна уметь безопасно возвращаться к правильному производному классу.

2. Транзитивность. Если а=>Ь, а=>с и b=>c2, то с и с2 должны быть эквивалентны; точнее, они должны быть гранями одного объекта, обеспечивающими идентичные наборы функциональных средств. При этом физически они могут быть разными гранями.

3. Устойчивость граней. Пока грань существует, она должна работать корректно. Иначе говоря, при удалении указываемого объекта все ссылающиеся на него грани после выполнения оператора ! начинают возвращать false и инициировать исключения при вызове функций. Это положение можно было бы сформулировать и более строго - указываемый объект не должен уничтожаться до тех пор, пока для него существует хотя бы одна грань. В частности, это правило используется в технологии СОМ.

Первые два правила выполнить несложно, хотя за это нередко приходится расплачиваться объемом и быстродействием. Посидите пару вечеров, набейте живот жирной пиццей, и вы наверняка сами придумаете, как обеспечить выполнение этих двух правил. Некоторые рекомендации приведены ниже. Устойчивость граней - совсем другое дело; мы констатируем проблему сейчас, но откладываем решение до следующих глав.

Симметричность

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

class BarFacet { private:

Bar* bar;

PointeeGemstone* gemstone; public:

BarFacet(Bar* b, PointeeGemstone* agg) : bar(b), gemstone(agg) {} operator PointeeGemstone() { return *gemstone; } Интерфейсы к функциям Bar

Наличие обратного указателя обеспечивает симметричность; по кристаллу можно .получить грань, а по грани - кристалл. Основная проблема состоит в том, что BarFacet не годится для повторного использования, если Ваг является компонентом различных кристаллов; для каждого использования приходится создавать отдельную грань.

Транзитивность

На самом деле соблюдение этого принципа зависит от дисциплины проектирования. Транзитивность нарушается в ситуациях наподобие следующей:

class Foo { private:

Blob* blob;

Bar* bar;

class Bar { private:

Blob* another b1ob;