straustrup2 (852740), страница 89

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 89)

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

Если ониесть, возникает двусмысленная ситуация, при которой типы, участвующие в циклах, становятсянесовместимыми в комбинации. Например:class Big_int {//...friend Big_int operator+(Big_int,Big_int);//...operator Rational();//...};class Rational {//...friend Rational operator+(Rational,Rational);//...operator Big_int();};Типы Rational и Big_int не так гладко взаимодействуют, как можно было бы подумать:void f(Rational r, Big_int i){//...g(r+i);// ошибка, неоднозначность:// operator+(r,Rational(i)) или// operator+(Big_int(r),i)329Бьерн Страуструп.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;// ...Трудно гарантировать, что информация, используемая в классах одного компонента, будет доступна330Бьерн Страуструп.Язык программирования С++только в одной единице трансляции, поскольку операции, работающие с этой информацией, должныбыть доступны везде.

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

Третье решениеможно рассматривать как формализацию и обобщение первых двух:class compX_details { // специфика реализации compXpublic: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;// ...};Использовать ли вложенность? Ответ на этот вопрос зависит от целей проекта и общностииспользуемых понятий. Как вложенность, так и ее отсутствие могут быть вполне допустимымирешениями для данного проекта.

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

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

Вероятнее всего, это произойдет для иерархии содним корнем, а для борьбы с этим явлением можно применять виртуальные базовые классы ($$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[].

Характеристики

Список файлов книги