Бьерн Страуструп.
Язык программирования С++
331
только в одной единице трансляции, поскольку операции, работающие с этой информацией, должны
быть доступны везде. Это решение может к тому же привести к громадным единицам трансляции, а в
некоторых отладчиках для С++ не организован доступ к именам статических
функций и переменных. В
то же время это решение надежно и часто оптимально для небольших компонентов. Третье решение
можно рассматривать как формализацию и обобщение первых двух:
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;
//
...
};
Использовать ли вложенность? Ответ на этот вопрос зависит от целей проекта и общности
используемых понятий. Как вложенность, так и ее отсутствие могут быть вполне допустимыми
решениями для данного проекта. Но поскольку вложенность предохраняет от засорения общего
пространства имен, в
своде правил ниже рекомендуется использовать вложенность, если только нет
причин не делать этого.
Бьерн Страуструп.
Язык программирования С++
332
Отметим, что заголовочные файлы дают мощное средство для различных представлений компонент
разным пользователям, и они же позволяют удалять из представления компонента для пользователя те
классы, которые связаны со спецификой реализации.
Другим средством построения компонента и представления его пользователю служит иерархия. Тогда
базовый класс используется как хранилище общих данных и функций. Таким способом устраняется
проблема, связанная с глобальными данными и функциями, предназначенными для реализации общих
запросов классов данного компонента. С другой стороны, при таком решении классы компонента
становятся слишком связанными друг с другом, а пользователь попадает в
зависимость от всех
базовых классов тех компонентов, которые ему действительно нужны. Здесь также проявляется
тенденция к тому, что члены, представляющие "полезные" функции и данные "всплывают" к базовому
классу, так что при слишком большой иерархии классов проблемы с глобальными данными и
функциями проявятся уже в рамках этой иерархии. Вероятнее всего, это произойдет для иерархии с
одним корнем, а для борьбы с этим явлением можно применять виртуальные базовые классы ($$6.5.4).
Иногда лучше выбрать иерархию для представления компонента, а иногда нет. Как всегда сделать
выбор предстоит разработчику.
Достарыңызбен бөлісу: