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

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

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

специфике C++ и граней, они также являются частью стандартной дисциплины проектирования, используемой в технологии СОМ компании Microsoft:

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;

};

Если обратиться к классу 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, и функции начинают инициировать исключения. Правда, остается другая проблема - когда и как удалять ведущиеуказатели. Ее также лучше рассматривать при обсуждении различных стратегий управления памятью.