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) классов указываемых объектов. Ведущие указатели помогают соблюсти некоторые из правил согласованности, о которых будет рассказано позже.
103
Проверка граней
Давайте еще немного расширим эту идиому и предположим, что некоторая грань может поддерживаться или не поддерживаться объектом. О том, почему и как это может произойти, мы поговорим во время изучения переходных типов далее в этой главе, а пока ответим на вопрос: как клиент может определить, поддерживается ли некоторый объект некоторой гранью? Решение построено на другом С++-изме — перегрузке оператора !.
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:
104
1. Симметричность. Если а=>b, то b=>а. Последствия: грань — переменная класса должна уметь восстанавливать вмещающий объект, из которого она получена, а грань — базовый класс должна уметь безопасно «возвращаться» к правильному производному классу.
2.Транзитивность. Если а=>b, а=>с и 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_blob;
};
105
Если обратиться к классу Foo с запросом на получение Вlob, он вернет вам то, на что ссылается его собственная переменная. Если запросить Bar, а затем у Bar запросить Blob, вы получите другой объект — тот, на который ссылается Bar.
Такая ситуация обычно встречается при множественном наследовании и многократном (хотя и косвенном) наследовании от одного базового класса. Если переработать приведенный выше фрагмент, ту же проблему можно легко воссоздать с применением наследования:
class Blob { ... };
class Foo : public Blob { ... };
class Bar : public Foo, public Blob { ... };
В этом фрагменте заложена неоднозначность. При преобразовании типа Bar* в Blob* непонятно, какой же Blob имеется в виду: непосредственно базовый для Bar или тот, от которого происходит Foo? Даже если вам удастся справиться с неоднозначностью, транзитивность все равно нарушается.
Как же избежать подобных проблем? Я мог бы пуститься в замысловатые объяснения, но все сводится к одному: следите за собой. Не наследуйте открыто от одного класса несколько раз в иерархическом дереве некоторого класса (с закрытым наследованием проблем обычно не возникает, поскольку нельзя выполнить преобразование к типу закрытого базового класса). Не внедряйте экземпляры одного класса в качестве переменных более чем одного компонента, а если уж вы это сделали — не предоставляйте интерфейсы более чем к одному из них.
Устойчивость граней
В эталонном C++ эта проблема возникает, например, при получении адреса переменной или базового класса и последующем удалении вмещающего объекта. Указатель на переменную или базовый класс превращается в мусор. Проблема обеспечения согласованности в такой неразберихе не решается за обедом в течение одного дня. Усиленная формулировка (указываемые объекты должны существовать до тех пор, пока для них существуют грани) откладывается до той части книги, которая посвящена управлению памятью. Слабая формулировка легко обеспечивается с помощью ведущих указателей. Если грань работает с объектом через ведущий указатель, то у ведущего указателя можно спросить: «А указываешь ли ты сейчас на существующий объект?» Если ответ будет отрицательным, оператор ! возвращает true, и функции начинают инициировать исключения. Правда, остается другая проблема
— когда и как удалять ведущие указатели. Ее также лучше рассматривать при обсуждении различных стратегий управления памятью.
Грани и ведущие указатели
Концепции граней и кристаллов хорошо сочетаются с концепцией ведущих указателей. Существуют два основных подхода.
Ведущий указатель в середине
Традиционный ведущий указатель (вероятно, с использованием оператора ->) вставляется между указываемым объектом и гранью. В этом случае грани превращаются в разновидность дескрипторов, косвенно обращающихся к членам указываемого объекта через ведущий указатель. Ведущий указатель должен уметь хотя бы генерировать кристалл, который затем будет использоваться клиентами для генерации других граней. Если весь доступ к объекту осуществляется через грани, подумайте о том, чтобы сделать оператор -> ведущего указателя закрытым, а грани объявить друзьями.
Превращение кристалла в ведущий указатель
Кристаллу присваиваются функции ведущего указателя. Затем кристалл генерирует грани и поддерживает семантику ведущего указателя для конструирования и уничтожения. Грани получают доступ к указываемому объекту через кристалл. Чтобы вам было удобнее, можно предоставить закрытый оператор -> в кристалле и сделать грани друзьями кристалла. Грани фактически превращаются в дескрипторы и получают доступ к указываемому объекту косвенно, через кристалл.