Бьерн Страуструп. Язык программирования С++. Специальное издание (2011) (1004033), страница 78
Текст из файла (страница 78)
*I ) ! в графической форме иерархия имеет вид: Такой набор связанных классов традиционно называют классовой иерархией наследования или просто классовой иерархией (с!авв Ь!сгатсйу). Ее чаще всего изображают в виде дерева, но она может иметь и более общую структуру графа. Например, для классов 12.2. Производные классы 379 Тетрогагу Етр!оуее лег Рггесгог Сопли!ган! Таким образом, как детально объясняется в 915.2, на С++ можно сформировать направленный ациклический граф классов. 12.2.5.
Поля типа Чтобы использовать производные классы в качестве чего-то большего, чем просто удобный способ сокращения исходного кода, мы должны решить следующую проблему: как определить истинный (производный) тип обьекта, адресуемого указателем типа Вазе* (то есть указателем на базовый класс)? Существуют четыре фундаментальных способа решения этой проблемы: 1. Гарантировать, что адресуются лишь объекты единственного типа (92.7, глава 13). 2.
Поместить специальное поле типа в базовый класс, чтобы функции могли его проверять. 3. Использовать с(унит(с сам (915.4.2, 915.4.5). 4. Использовать виртуальные функции (92.5.5, 912.2.6). Указатели на базовые классы широко используются при проектировании контейнерных классов (сонгатег с(атее), таких как множества (зе(), вектора (нес(ог) и списки (1(в(). В таких случаях решение [1] приведет к однородному списку, то есть списку объектов одного и того же типа. Решения [2], [3] и [4] позволяют строить списки разнородных объектов, то есть списки указателей, настроенных на объекты разных типов.
Решение [3] является вариантом решения [2], которое поддерживается языком С++ непосредственно. А решение [4] является специальным вариантом решения [2), безопасным по отношению к типам. Комбинация решений [1] и [4) особо интересна и чрезвычайно мощна, и почти всегда способствует более ясному коду, чем код, порождаемый решениями [2) и [3]. Рассмотрим сначала решение, основанное на полях типа с тем, чтобы понять, почему его в большинстве случаев лучше избегать. Наш пример с сотрудниками и менеджерами можно переопределить следующим образом: еггис! Етр(оуее ( енит Етр! (уре (М, Е); Етр! (уре (уре; Етр(оуее(): (уре(Е) () 380 Глава 12. Наследование классов з(г(пЛЯя( пате, (ать нате; слог тиЫ1е !и!((а1; Ва(е Ь(г!ня ((а(е( яао(( ((ераг(теп(( УУ ... )( я(гис( Мапааег: риЬЕс Етр(оуее ( Маиаяег() ((уре = М( ) УУ подчиненные (Ь(<Етр(оуее* > егоир; злог( 1еге1( уу ...
)( Теперь мы можем написать функцию, выводящую информацию о каждом сотруднике; гоЫ рг(л( етр(оуее (сопя( Етр!оуее* е) ( яндсЬ (е->(уре) ( саяе Етр(оуее:: Е: сои(« е->Гатйу пате« ' ~(' << е->((ераг(теи(<< ' '~п' ( УУ ... Ьгеаа( сазе Етр!оуее:: М: ( сои(« е->/атИу пате« ' ~(' << е->((ераг(тен(« ' '~п '; уу ... сопя( Мапавег* р = я(а(Ь сам<соня( Мапакег*> (е) ( сои(« "1еге(н «р->(еге1« ' ~и '; уу ...
Ьгеаа; ) ) ) Используем эту функцию для вывода элементов списка: чоЫ ргт( !и( (соня( (Ь(<Етр!оуее*> з е!Ь() ( /ог (!Ь(<Етр1оуее * >:: сопя( пега(ог р = е((з(. Ьея!л ( ); р! =е!Ь(. еп(( ( ) ( е +р ) рлл( етр!оуее (*р); ) г Все это прекрасно работает, особенно в маленьких программах, поддерживаемых единственным программистом.
В то же время, представленное решение имеет и фундаментальную слабость, так как зависит от манипуляций с типами, которые не контролируются компилятором. Положение становится еще хуже, если функции, вроде рг(л( етр!оуее() пытаются извлечь пользу из общности типов: ЗВ1 12 2 Производные классы гоЫ рнпг етр)оуее (сапог Етр)оуее* е) сои)« е->уат11у пате« ' ~1'<< е->аераг)теис<< ' ~и' У.. (у( е->гуре == Етр)оуее::М) ( сапог Мападег* р = тацс сам<соле) Мападег*> (е); сои)« "1еге1" «р->1еге1« ' ~и '; ~У...
) ) Поиск всех проверок типа, глубоко запрятанных в коде больших функций, да еше и при наличии большого числа производных классов, весьма утомителен. Даже если все проверки найдены, бывает непросто понять, что на самом деле происходит. Более того, если добавляется новый тип сотрудников (производный от Етр1оуее класс), то приходится вносить изменения во все ключевые функции системы — те, что проверяют поля типа. После внесения изменений программист должен проверить все функции, потенциально зависящие от проверок типа. Это подразумевает, что программист должен иметь доступ к ключевым частям исходного кода программы, а также дополнительные усилия по тестированию программы.
В итоге становится понятным, что наличие проверок типа служит отчетливым сигналом о необходимости улучшения кода. Другими словами, техника применения полей типа способствует ошибкам и усложняет сопровождение. Проблема усиливается чрезвычайно по мере роста размеров программ, ибо поля типа нарушают все принципы модульности и сокрытия данных. Каждая функция, использующая поля типа, должна знать детали представления всех производных классов иерархии (с базовым классом, содержащим поле типа). Также складывается впечатление, что наличие общих данных, доступных из всех классов иерархии наследования, провоцирует программистов на увеличение числа таких данных. В итоге, общий базовый класс становится чем-то вроде склада всякой «полезной информации».
Это, в свою очередь, порождает крайне нежелательные связи между реализациями базовых и производных классов. Ясный дизайн и простота сопровождения требуют, чтобы разные сущности представлялись раздельно, а взаимозависимости между ними минимизировались. 12.2.6. Виртуальные функции Виртуальные функции решают проблему полей типа, предоставляя программисту возможность определить в базом классе функции, подлежащие замещению в каждом производном классе. Компилятор и загрузчик гарантируют правильное соответствие между объектами и применяемыми к ним функциями. Например: с1ат Етр!оуее ( егг)иду)гт пате, уат11у пате; ейогг Иераггтеиг; У... риЫ)с: 382 Глава ) 2. Наследование классов Етр!оуее (сопл! и!пода пате, 1л! Иер!) г1ггиа! гоЫ ргт! ( ) солт; /У ... )' Ключевое слов Ыггиа1 указывает, что функция рг(лг( ) символизирует общий интерфейс к набору одноименных функций, определенных в базовом и производных от него классах.
Если такие функции действительно определены в производных классах, компилятор гарантирует вызов своего варианта функции рпп!() для каждого объекта классовой иерархии. Чтобы объявление виртуальной функции действительно работало в качестве интерфейса к семейству функций, определенных в базовом и производных классах, типы аргументов всех функций должны быть одинаковыми, а для возвращаемого значения допускаются лишь незначительные отличия (815.б.2). Виртуальные функции-члены иногда называют методами'. Виртуальная функция обязана быть определена в классе, в котором она впервые объявляется (за исключением случаев чисто виртуальных функций; см.
812.3). Например: гоЫ Етр(оуее::рпт() соле! ( сои!« ГатИу пате« ' ~!'<< дерег!тел!<< ' ~п '; // ... ) Разумеется, виртуальную функцию можно использовать и в случаях, когда у класса отсутствуют производные классы. Производный класс, который не нуждается в собственном варианте функции, не обязан замещать виртуальную функиию, определенную в базовом классе.
Определяя производный класс, определите и новый вариант виртуальной функции, если он, конечно, нужен. Например: с!от Мападег:риЫЫ Етр!оуее ( 1Ы!<Етр(оуее* > ягоир ! в)зогг 1еге1; У... риЫ!с: Мападег (сопл! з!подь пате, (л! Мер!, (п! 1г1) ) еоЫрплг() соплы У ... )' соЫМапалег::рпп!() сопл! Етр1оуее:: рпл! ( ); Саи!«пМЕГЕ1" «1ЕЕЕ! « ' Хл'; /У ... 1 Чаще всего методами называют любые классовые функции-члены. — Прим.
ред. 12.2. Производные классы 383 Функция производного класса, имеющая то же имя и те же параметры, что и виртуальная функция, определенная в базовом классе, замен(ает (очеггЫе) вариант от базового класса. За исключением случаев прямых указаний на конкретный вариант используемой виртуальной функции (например, Етр1оуее::рппг() ), выбирается замещаемая для класса объекта функция. Теперь отпадает нужда в глобальной функции рг(и! етр1оуее() (В)2.2.5), поскольку ее место занято функциями-членами рг!иг() . Список сотрудников теперь выводится следующим образом: чо!4рпп! 11з((соиз! 11т<Етр(оуее*>з з) ( уог (Взг<Етр1оуее*>:: солт Вега!ог р = з. Ьеа!п ();р! =з. епй() ! ««р) («р) ->рпиз(); ) Усм. 32.
7.2 Илн еще проще: чай! рг1п! Вза ( сола! !1з!<Етр1оуее «> З з ) ( Гог еасЬ (з. Ьеа!и (), з. еп4(), тет 1ил (зЕтр!оуее::рпи!) ) ) Усм. 33.(1.5 Информация по каждому сотруднику выводится точно в соответствии с его настоящим статусом. Вот иллюстрация к сказанному, где функция та)п (): !п! та1п () Етр!оуее е ( "Вго«чи", 1234); Ыапааег т ( пблиУВ", 1234, 2); 11зг<Етр!оуее«> еизр1! етр1. ризя угол! ( з е ); етр!.ризь !гоп! (ат) ! рг(п! 11з! (етр1); У см. ~2.5.4 порождает следующий вывод; Ят!!Ь 1234 1ече1 2 Вгопи 1234 Заметим, что все это работает даже в случае, когда функция рг(п! 11з!() написана и откомпилирована до того, как класс Мапааег был разработан (и даже задуман). Вот это действительно ключевой аспект работы с классами.
При правильном использовании он служит краеугольным камнем объектно-ориентированного проектирования и придает стабильности эволюционирующим проектам. «Правильное> поведения виртуальных функций рплю! ) для любых сотрудников компании (то есть для любых объектов типа Етр1оуее, Маиаяег и прочих производных классов) называется полиморфизмом (ро(утогрЫзт).
Тип с виртуальными функциями называется полиморфлым типом (ро1утогрй!с (уре). Для практической реализации полиморфного поведения в языке С++ тип объектов должен быть полиморфным, а сами объекты должны адресоваться указателями или ссылками. Когда же с объектами работают напрямую (а не косвенно через указатели или 384 Глава 12 Наследование классов ссылки), то их тип известен компилятору заранее и никакого полнморфизма просто не требуется. Ясно, что для реализации полиморфизма, компилятор должен хранить с каждым объектом полиморфной классовой иерархии дополнительную информацию о типе, чтобы иметь возможность вызвать правильную версию виртуальной функции. В типичной реализации достаточно дополнительной памяти для хранения указателя (в2.5.5). Эта дополнительная память относится только к объектам классов с виртуальными функциями, а вовсе не ко всем объектам любых классовых иерархий. Отметим, что в рассмотренном выше случае, когда применяется поле типа, величина требуемой избыточной памяти ничуть не меньше.
Вызов функции с применением операции разрешения области видимости::, как это было сделано в Мииаяег::рггиг(), гарантирует «выключение» механизма виртуальных функций. В противном случае, вызов Мииаяег::рггяг() привел бы к бесконечной рекурсии. Использование квалифицированных имен имеет еше один положительный эффект. Если виртуальная функция объявлена встраиваемой (что нередко встречается), то применение операции:: позволяет действительно встраивать ее вызов. А это помогает программисту уладить деликатную проблему вызова виртуальной функции из другой виртуальной функции для того же самого объекта.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
