Б. Страуструп - Язык программирования С++. Специальное издание, 3-изд. Бином. 2004 (1160791), страница 189
Текст из файла (страница 189)
24.3.5. Отношения использования Знание того, какие другие классы используются данным классом и как именно, часто критически важно для выражения и понимания проекта. Такие зависимости поддерживаются С++ только неявно. Класс может использовать только имена, которые были (где-то) объявлены, но список использованных имен не обеспечивается исходным кодом С++.
Для извлечения такой информации необходимы инструментальные средства программирования )или при отсутствии соответствующих средств — внимательное чтение). Способы, которымн класс Х может пользоваться другим классом У, можно классифицировать по-разному. Например, так: Х пользуется именем У; Х пользуется У; ° Хвызывает функцию-член У; Х читает член класса У; Х записывает член класса У; 822 Глава 24.
Проектирование и программирование ° Х создает У; ° Х выделяет память под автоматические и статические переменные класса У; Хсоздает Упри помощи пеш; Х принимает размеры класса К Принятие в качестве аргумента размеров объекта классифицируется как создание, поскольку это требует знания полного объявления класса. С другой стороны, пользование именем Укласснфицируется как отдельная зависимость, поскольку просто употребление имени — например, в обьявлении У* или упоминание Ув объявлении внешней функции — совсем не требует доступа к объявлению УЯ 5.7): с!аее У; О У вЂ” ипк некоторого класса У р' ех 1егп УУ Дсопее У8); Часто важно различать зависимости интерфейса класса (объявления класса) и зависимости реализации класса (определения членов класса).
В хорошо спроектированной системе, последние, как правило, имеют еще много зависимостей, и они гораздо менее интересны для пользователя, чем зависимости объявлений класса гз 24А.2). Как правило, цели проектирования заключаются в минимизации зависимостей ин терфейса, так как они становятся зависимостями пользователей класса Я 8.2А.1, 4 9,3.2, ф 12А.1.1, ~ 24А).
От тех, кто реализует класс, Се+ не требует детально описывать, какие используются другие классы и как именно. Одна из причин этого заключается в том, что большинство важных классов зависят от стольких других, что для читабельности перечень этих классов пришлось бы сократить -- например, директивой 41пс1ис7е.
Другая причина в том, что классификация и мельчайшие подробности таких зависимостей не представляются вопросом, который должен решаться языком программирования. С другой стороны, то, как именно рассматриваются зависимости использования, зависит от целей проектировщика, программиста или инструментальных средств.
И наконец, какие зависимости представляют интерес, также может зависеть от деталей реализации языка. 24.3.6. Запрограммированные отношения Язык программирования не может — и не должен — напрямую поддерживать все концепции всех методов проектирования. Подобным образом и язык проектирования не должен поддерживать все особенности всех языков программирования. Язык проектирования должен быть богаче и менее озабочен деталями, чем язык для программирования систем. И наоборот, язглк программирования должен уметь поддерживать различные философии проектирования, или он потерпит неудачу из-за неспособности приспосабливаться к ним.
Когда язык программирования не обеспечивает средств для прямого представления понятий проекта, необходимо использовать удобное отображение конструкций проекта в конструкции языка программирования. Например, метод проектирования может пользоваться понятием делегирования. То есть проект может специфицировать, что все операции, не определенные для классаА, должны обслуживаться объектом класса В, на который указывает указатель р.
Сев не может выразить это напрямую. Однако можно представить стилизацию этой идеи на Сее и написать программу, генерирующую соответствующий код. Рассмотрим пример; 823 24.3. Классы с(авв В ( //... оо(г(/(); ооЫд (); ооЫй (); с(авеА( В" р; //- -Ы./(); ооЫ/г () ); Спецификация того, что А делегирует полномочия В через Аср, даст следуюгций код: с!аввА ( 8" р; // делегирование через р О..' поЫ /(); соЫ//(); ооЫ а () ( р->а (); ) ооЫ Ь () ( р->Й (); ) Программисту ясно, что здесь делается, но имитация проектного понятия в коде далека от отношения взаимнооднозначного соответствия.
Такие «запрограммированные» отношения не «понимаются» языком программирования, и поэтому онн менее доступны для инструментальных средств. Например, стандартные инструментальные средства не распознают «делегирование» от А к В через Аср, как нечто отличное от других использований В*. Взаимнооднозначное соответствие между проектными понятиями и понятиями языка программирования нужно использовать при всякой возможности. Взаимнооднозначное соответствие обеспечивает простоту и гарантирует, что проект действительно отображается в программе, так что программисты и инструментальные средства могут воспользоваться этим.
Операторы преобразования предоставляют языковой механизм для выражения класса запрограммированных отношений. То есть оператор преобразованняХсорега1ог У() говорит, гто всегда, когда допустим У, можно использовать Х Я 11А.1). Конструктор У лУ (Х) выражает то же самое отношение. Отметим, что оператор преобразования (и конструктор) производят новый объект, а не изменяют тип существующего. Объявление функции преобразования в У вЂ” это просто способ запросить неявное применение функции, которая вернет У Поскольку неявное применение преобразований, определяемых конструкторами и операторами преобразования, может порой оказаться предательским, иногда при проектировании полезно анализировать их отдельно.
Важно гарантировать, что графы преобразований для программы не содержат циклов. Если они содержат циклы, ошибки неоднозначности сделают невозможным комбинирование входящих в цикл типов Например: с1аевйа1!оиа1; //рациональное висло с1аве Вц( (и1 ( // болыиое целое раб 11с: 824 /г!епс!В!д сп1 орега1ог» (В(у !пб В(д !п1) орега1ог )!а1!опа! (), //- ); с1азз Яаг!ола! ( риЬИс: Хт(епг! йа1!опа1 орета1ог» Да(!опа1, Ла1(опа1); орегагогВ!д ин (), Типы Иайопа1 и В!д 1п! взаимодействуют не так гладко, как кто-то мог бы надеяться: ио(с!/(!1а11опа! г, В(у (п() д' (г«я); я (г»ра1!опа! (!)); 4(В!4 ! 1()+1); ) Можно избежать таких «взаимных» преобрааований, сделав хотя бы некоторые из них явными.
Например, преобразование В!д 1п! в Яа11огга! вместо оператора преобразования можно определить как тале Ва((опа! (), и тогда сложение разрешилось бы как д (В1д 1п1(г), !). Там, где операторов «взаимного» преобразования не избежать, нужно разрешать получающиеся конфликты либо явными преобразованиями, как показано выше, либо определять много различных версий бинарнеях операторов, таких как+. 24.3.7. Отношения внутри кпасса Класс может скрывать почти неограниченное количество деталей реализации и почти неограниченное колнчество мусора — и иногда ему приходится зто делать.
Однако сами объекты большинства классов имеют регулярную структуру, и легко описать, как ими манипулировать. Объект класса — это набор других подобъектов (которые часто называют членами), и многие из ннх являются указателями и ссылками на другие об ьекты, Таким образом, объект можно представить себе как корень дерева объектов, а упомянутые выше объекты образуют как бы «иерархию объектов», дополняющую иерархию классов, как описано в 5 24.3.2,1. Например, рассмотрим очень простой класс аппп. //.
); Объскт Яг1пдможно представить графически следу1ощим образом: с!азз 31г!пи ( тп! зе; сваг* р; рибйс: 81г!п!1 (сопя! спит*у); -81г!пд(); Глава 24. Проектирование и программирование //ошибка, неоднозничностгс орета1ог+(т, йа1!опа!(!)) //или орето1ог«(8~д гп1(г), !)? // одно явное ри.зрешение // другое яе нос разрешение 825 24.3. Классы 24.3.7.1. Инварианты с1авв 81г1ла ( 1л1жс сааг* р, риЫ1в с1авв Аале ( ); с(аах 1аиаг1ал1(); // классы исключений /1 проверка инварианта иоиб сйвск (), 51г(ад )соав1сааг а); 8 1г(аа (солв1 8 1ггад&) -81г(ад (); Значения членов и объектов, на которые ссылаются члены, собирательно называются состоянием объекта Гали просто его значением). Главная забота при проектировании класса — привести об ьект н четко определенное состояние (инициализация/конструирование), поддервкивать четко определенное состояние при выполнении операций и наконсц изящно уничтожить объект.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
