g(r,Rational(i)); g(Big int(r),i);

Можно было бы избежать таких взаимных преобразований, сделав некоторые из них явными. Например, преобразование Big int к типу Rational можно было бы задать явно с помощью функции make Rational() вместо операции преобразования, тогда сложение в приведенном примере разрешалось бы как g(BIg int(r),i). Если нельзя избежать взаимных операций преобразования типов, то нужно преодолевать возникающие столкновения или с помощью явных преобразований (как было показано), или с помощью определения нескольких различных версий бинарной операции (в нашем случае +).

12.3 Компоненты

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

Рассмотрим два класса, которые должны совместно использовать функцию f() и переменную v. Проще всего описать f и v как глобальные имена. Однако, всякий опытный программист знает, что такое засорение пространства имен может привести в конце концов к неприятностям: кто-то может ненарочно использовать имена f или v не по назначению или нарочно обратиться к f или v, прямо используя специфику реализации и обойдя тем самым явный интерфейс компонента. Здесь возможны три решения:

[1 ] Дать необычные имена объектам и функциям, которые не рассчитаны на пользователя.

[2] Объекты или функции, не предназначенные для пользователя, описать в одном из файлов программы как статические (static).

[3] Поместить объекты и функции, не предназначенные для пользователя, в класс, определение которого закрыто для пользователей.

Первое решение примитивно и достаточно неудобно для создателя программы, но оно действует:

не используйте специфику реализации compX, если только вы не разработчик compX: extern void compX f(T2*, const char*); extern T3 compX v;

Такие имена как compX f и compX v вряд ли могут привести к коллизии, а на тот довод, что пользователь может быть злоумышленником и использовать эти имена прямо, можно ответить, что пользователь в любом случае может оказаться злоумышленником, и что языковые механизмы защиты предохраняют от несчастного случая, а не от злого умысла. Преимущество этого решения в том, что оно применимо всегда и хорошо известно. В то же время оно некрасиво, ненадежно и усложняет ввод текста. Второе решение более надежно, но менее универсально:

специфика реализации compX:

static void compX f(T2* a1, const char *a2) { /* static T3 compX v;

*/ }

Трудно гарантировать, что

информация, используемая

в классах одного компонента, будет доступна

явное разрешение неопределенности еще одно

только в одной единице трансляции, поскольку операции, работающие с этой информацией, должны быть доступны везде. Это решение может к тому же привести к громадным единицам трансляции, а в некоторых отладчиках для С++ не организован доступ к именам статических функций и переменных. В то же время это решение надежно и часто оптимально для небольших компонентов. Третье решение можно рассматривать как формализацию и обобщение первых двух:

class compX details { специфика реализации compX public:

static void f(T2*, const char*); static T3 v; ...

Описание compX details будет использовать только создатель класса, остальные не должны включать его в свои программы.

В компоненте конечно может быть много классов, не предназначенных для общего пользования. Если их имена тоже рассчитаны только на локальное использование, то их также можно спрятать внутри классов, содержащих специфику реализации:

class compX details { специфика реализации compX. public: ...

class widget { ...

Укажем, что вложенность создает барьер для использования widget в других частях программы. Обычно классы, представляющие ясные понятия, считаются первыми кандидатами на повторное использование, и, значит составляют часть интерфейса компонента, а не деталь реализации. Другими словами, хотя для сохранения надлежащего уровня абстракции вложенные объекты, используемые для представления некоторого объекта класса, лучше считать скрытыми деталями реализации, классы, определяющие такие вложенные объекты, лучше не делать скрытыми, если они имеют достаточную общность. Так, в следующем примере упрятывание, пожалуй, излишне:

class Car {

class Wheel { ...

Wheel flw, frw, rlw, rrw; ...

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

class Wheel { ...

class Car {

Wheel flw, frw, rlw, rrw; ...

Использовать ли вложенность? Ответ на этот вопрос зависит от целей проекта и общности используемых понятий. Как вложенность, так и ее отсутствие могут быть вполне допустимыми решениями для данного проекта. Но поскольку вложенность предохраняет от засорения общего пространства имен, в своде правил ниже рекомендуется использовать вложенность, если только нет причин не делать этого.

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

Другим средством построения компонента и представления его пользователю служит иерархия. Тогда базовый класс используется как хранилище общих данных и функций. Таким способом устраняется проблема, связанная с глобальными данными и функциями, предназначенными для реализации общих запросов классов данного компонента. С другой стороны, при таком решении классы компонента становятся слишком связанными друг с другом, а пользователь попадает в зависимость от всех базовых классов тех компонентов, которые ему действительно нужны. Здесь также проявляется тенденция к тому, что члены, представляющие полезные функции и данные всплывают к базовому классу, так что при слишком большой иерархии классов проблемы с глобальными данными и функциями проявятся уже в рамках этой иерархии. Вероятнее всего, это произойдет для иерархии с одним корнем, а для борьбы с этим явлением можно применять виртуальные базовые классы ($$6.5.4). Иногда лучше выбрать иерархию для представления компонента, а иногда нет. Как всегда сделать выбор предстоит разработчику.

12.4 Интерфейсы и реализации

Идеальный интерфейс должен

- представлять полное и согласованное множество понятий для пользователя,

- быть согласованным для всех частей компонента,

- скрывать специфику реализации от пользователя,

- допускать несколько реализаций,

- иметь статическую систему типов,

- определяться с помощью типов из области приложения,

- зависеть от других интерфейсов лишь частично и вполне определенным образом.

Отметив необходимость согласованности для всех классов, которые образуют интерфейс компонента с остальным миром, мы можем упростить вопрос интерфейса, рассмотрев только один класс, например:

class X { пример плохого определения интерфейса

Y a; Z b; public:

void f(const char* ...);

void g(int[],int);

void set a(Y&);

Y& get a();

В этом интерфейсе содержится ряд потенциальных проблем:

- -Типы Y и Z используются так, что определения Y и Z должны быть известны во время трансляции.

- У функции X::f может быть произвольное число параметров неизвестного типа (возможно, они каким-то образом контролируются строкой формата , которая передается в качестве первого параметра).

- Функция X::g имеет параметр типа int[]. Возможно это нормально, но обычно это свидетельствует о том, что определение слишком низкого уровня абстракции. Массив целых не является достаточным определением, так как неизвестно из скольких он может состоять элементов.

- Функции set a() и get a(), по всей видимости, раскрывают представление объектов класса X, разрешая прямой доступ к X::a.