Б. Страуструп - Язык программирования С++. Специальное издание, 3-изд. Бином. 2004 (1160791), страница 188
Текст из файла (страница 188)
риЫье В ( риЫле: ооЫХО; ); ооЫ Ь2 (Р2' рд) Отметим, что не существует неявного преобразования из класса в один из его членов, и что класс, содержащий член другого класса, не залзещает виртуальных функций того класса. Это очевидно контрастирует со случаем открытого наследования: Глава 24. Проектирование и программирование 818 11 правильно: неявное преобразование 02* в В" О вызывает Вку О вызывает Вну 11 виртуальный вы зов г обращение к 02г У' О обращается к 02::! В рЬ=рд; рь- у(), рд-'у() рь- !(); рс(-'з'()' Удобство записи в примере с 02 по сравненсию с примером с 01 является поводом к злоупотреблению.
Надо помнить, что за удобство записи приходится платить возросшей зависимостью между В2 и 02 (см. ~ 24.3.2.1). В частности, легко забыть о неявном преобразовании из 02 в В. Если так ис преобразования не являются допустимой частью семантики ваших классов, открьапого наследования следует избегать. Когда же класс используется для представления понятия, а наследование используется для представления отношения !з-а, такие преобразования очень часто оказываются именно тем, что нужно. Сушествуют случаи, когда вам нравится наследование, но вы не можете себе позволить таких преобразований. Рассмотрим написание класса С!)еИ (управляемое поле), который — кроме всего прочего — обеспечивает динамическое (на этапе выполнения) управление доступом для другого класса г!е1а (поле).
На первый взгляд, сделать С!!еЫ производным от Р!е1Ы вполне разумно: с! авз СУ!е!д ри Ьвс Рге!д (1* ... "1 ); Это выражает тот факт, что Сг)еЫ является разновидностью Р!еИ, допускает более удобную запись при написании функций класса СЯеЫ, которые пользуются членами из части С!!е1а', и — самое важное — позволяет классу СЯеИ замещать виртуальные функции класса г!еИ.
Неприятность заключается в том, что преобразование С1)еЫ* в Р!еИ*, подразумеваемое в объявлении С!зеИ, делает бессмысленными все попытки управлять доступом к р!еЫ ооЫ д (СГ!еЫ' р) ( 'р = 'авду"; ,Ч доступ к аолнз, контролируемый оператором 11 присваивания из С))е!д; р — ) С!) е!дггорегагог=("аз4") О неявное преобразование С1)е!д* в Не!д' 11 ОШИБ!сд! никакого контроля Р!е1с!' д = р; *у = аздз'; ) Решением могло бы стать определение СЯе!с! такьлм образом, чтобы Р!еЫ было его членом, но это не даст возможности СНЫ замещать виртуальные функции РсеЫ Лучшее решение — использовать закрытое наследование: с!аев С)(е!д: рп''оагеР!е!й(1" ... '1 ); С точки зрения проектирования закрытое наследование равносильно включению, если не считать (иногда очень важного) вопроса с замещением.
Важное применение такого полхода — прием с открытым наследованием из абстрактного базового класса, определяюшего интерфейс, и одновременным зашишенным или закрытым наследованием от конкретного класса для предоставления реализации Я 2.5.4, Э 12.3, 8 25.3). Посколск ку построение производных классов, подразумеваемое закрытыи и заи(ии(енным наследованием, является деталью реализации, которая не влияет на тип производного 819 24.3. Классы класса, его и ногда назгя вают наследованием реализации, и оно противопоставляется открытому наследованию, посредством ко~срого интерфейс базового класса наследуется и неявное преобразование в базовый тип становится допустимым.
Последнее иногда называют подтипизацией или наследованием интерфейса, Другой способ выразить то же самое — сказать, что объектом производного класса можно пользоваться там, где допустим объект открытого базового класса. Это иногда называют «принципом подстановки Лисков'» Я 23.6 ((ззкоч, ) 987)). Различение между открытым, защищенным и закрытым наследованием непосредственно поддерживает это для полиморфных типов, к которым мы обращаемся посредством указателей и ссылок. 24.3.4.1.
Альтернатива «членство/иерархия» Чтобы еще глубже разобраться с выбором между включением и наследованием, рассмотрим, как представить полосу прокрутки в интерактивной графической системе, и как связать зту полосу с окном. Нам нужны две полосы прокрутки: горизонтальная и вертикальная. Мы можем представить это либо двумя типами — Напаоп1а( зсгоПЬаг и )гегг!са! зсгоПЬаг — либо одним типом Ясго(16агс аргументом, указывающим, верти. кальная ли это полоса прокрутки или горизонтальная, Первый вариант подразумевает необходимость введения третьего типа, просто полосы прокрутки Зсго(!Ьаг, выступаюгцего в качестве базового класса для двух частных типов полос. Второй вариант предполагает необходимость введения дополнительного аргумента для указания типа полосы и выбора значений, представляющих эти два типа.
Например: епит Оггепга11оп ( Ьоггзоп1а1, нег!1«а! ); Когда выбор сделан, он определяет, какие изменения нужны для расширения системы. В примере с полосами прокрутки нам может понадобиться ввести третий тип полосы. Сначала мы могли подумать, что нужно лишь два вида таких полос прокрутки («в конце концов, окно имеет только два измерения>). Однако в данном случае — как и в большинстве других — возможны расширения, которые проявляются при перепроектировании.
Например, кому-то может захотеться вместо двух полос сделать одну «навигационную кнопку» (пан(йайоп Ьцггоп). Такая кнопка будет приводить к прокрутке в разных направлениях в зависимости от того, с какой стороны пользователь ее нажал. Щелчок в середине ее верхней части будет означать «прокрутку вверх», щелчок в середине левой части — «прокрутку влево>, щелчок в левом верхнем углу — «прокрутку вверх и влево».
Такие кнопки встречаются. Их можно рассматривать как развитие идеи полос прокрутки; они особенно удобны в тех прикладных программах, где прокручиваемая информация — не просто текст, а изображения более общего вида. Добавление навигационной кнопки в программу с иерархией классов с тремя полосами прокрутки влечет за собой добавление еще одного класса, но не требует изменений в коде старой полосы прокрутки; Ноыеопга! »сгоПЬаг Уегг(са( зсгоПЬаг пап!йа11оп Ьижоп Это приятный аспект «иерархического> решения.
' Барбары Лисков. — Примеч. ред. 820 Глава 24. Проектирование и программирование Задание ориентации полосы прокрутки в качестве аргумента подразумевает наличие полей типа в объектах, отвечающих полосам прокрутки, и использование инструкции зшйсй в коде функций-членов класса Зсго<<Ьаг, То есть мы столкнулись с выбором между выражением этого аспекта структуры системы посредством объявлений или посредством кода. Первый выбор улучшает статическую проверку и увеличивает объем информации, доступной инструментальным средствам. Второй вариант откладывает решение на время выполнения программы и позволяет вносить изменения, модифицируя отдельные функции и не касаясь общей структуры системы, как ее видят система контроля типов и другие инструментальные среде~за.
Лично я рекомендую, в большинстве случаев, для прямого моделирования иерархических отношений между понятиями пользоваться иерархией классов. Решение с одним типом полосы прокрутки облегчает хранение и передачу информации, задающей внд прокрутки: иов! Ье1рег (Опеп!а поп ао( < //- р = пега ЯсгоПЬаг (ао(; //- эо<й зпе 0 Ье1рег (дог!гоп!аГ<; //- Такое представление также упростило бы переориентацию полос во время выполнения программы. Вряд ли это имеет большое значение для полос прокрутки, но есть много схожих примеров, где зто важно.
Главное в том, что в этом вопросе всегда существует выбор, причем зачастую трудный. 24.3.4.2. Альтернатива «включение/иерархия» Теперь рассмотрим, как привязать полосу прокрутки к окну. Если мы считаем класс !Гг!пг/ога пп!Ь зсгоПЬаг <окно с полосой прокрутки) чем-то таким, что является и окном, и полосой прокрутки, то получим следующее: с<азз (е!пйогз вз!Ь зегоПЬаг: риЬПе (Г<пйои, риЬПе ВегоПЬаг ( //... Это позволит л1обому К<!!!!ота ш!!Ь зсгоПЬаг действовать и как ЯсгоПЬаг, и как Ф<пс<ота, но вынуждает нас использовать решение с одним типом полосы прокрутки. С другой стороны, если мы рассматриваем ззттс<ота ий!Ь зсгаНЬаг как окно, имеющее полосу прокрутки, то получим следующее: е1азз ЧПпг!о!з и!!6 .зсгоПЬаю". риЬПе Иг!пг<ою ( //.
ЗсгоПЬаг* зЬ; риЫ<е: (Ггипуоэ е<!6 зсгоПЬа«(5егоПЬаг*р,/*,."/): 821 24.3. Классы Въыощ (/' ... *('), зь (л) ( ( ... *1) Это позволяет нам применить реп~ение с иерархией полос прокрутки. Задание полосы в качестве аргумента позволяет окну не знать точный тип своей полосы. Мы можем даже передавать ЗсгоПЬаг так же, как мы передавали ориентацию Ог(ел(а((ол Ц 24.3.4.1). Если нам понадобится, побы Кале(ого щПЬ еегоПЬаг действовало как полоса прокрутки, мы можем добавить оператор преобрааования; В'шдогв влЯ зсгоПЬагэорега(ог БсгоПЬагй () ( ге(игл 'еЬ; ) По-моему, предпочтительнее, когда окно содержит в себе полосу прокрутки.
Мне легче вообразить окно, имеюа(ее полосу прокрутки, чем окно, которое, будучи окном, являел(ся еще и полосок прокрутки. По сути дела, моя излюбленная стратегия проектирования состоит в том, чтобы сделать полосу прокрутки специальной разновидностью окна, а затем включить ее в окно, которое нуждается в услугах полосы прокрут кн. Подобная стратегия приводит к решению в пользу включения. Другой аргумент в пользу того же решения проистекает из эмпирического правила «может лн оно иметь их две?» Я 24.3.4). Поскольку нет никаких логических причин, почему бы окно не могло иметь две полосы прокрутки (ведь на самом деле многие окна имеют горизонтальную и вертикальную полосы прокрутки), класс Р7л((ов в((Ь есгоПЬаг не следует делать производным от ЗсгоПЬаг.
Отметим, что нельзя создать производный класс от неизвестного класса. Во время компиляции должен быть известен точный тип базового класса 1ф 12.2). С другой стороны, если атрибут класса передается его конструктору в качестве аргумента, то где-то в классе должен быть представляющий его член. Однако если этот член— указатель нли ссылка, мы можем передать объект класса производного по отношению к классу, указываемому этим членом. Например, член еЬ типа ВсгоПЬаг* в предыдущем примере может указывать на ЯсгоПЬаг такого типа как ()(ап(Па((ол Ьи((ол, неизвестного пользователям ЗсгаПЬаг*.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
