С++ для "чайников" .

ОГЛАВЛЕНИЕ

В этой главе...

►Зачем нужно наследование 234

►Как наследуется класс 234

►Отношение СОДЕРЖИТ 238

В этой главе обсуждается наследование ( inheritance ), т.е. способность одного класса наследовать возможности или свойства другого класса. Наследование — это общепринятая концепция. Я — человек ( за исключением раннего утра... ). И я наследую некоторые свойства класса Человек, например возможность говорить ( в большей или меньшей степени ), интеллект ( надеюсь, что в большей степени ), необходимость в воздухе, воде, пище и разных витаминах. Эти свойства не являются уникальными для каждого отдельного человека. Очевидно, что класс Человек наследует зависимость от воды, воздуха и пищи у класса Млекопитающие, который, в свою очередь, наследует эти свойства у класса Животные.

Концепция, в основе которой лежит способность передавать свойства по наследству, очень мощная. Благодаря ей можно значительно сэкономить место при описании реального объекта. Например, если мой сын спросит: "Что такое утка?", я смогу сказать: "Это птица, которая крякает". Несмотря на краткость, этот ответ несёт в себе всю необходимую для описания утки ( по крайней мере, для моего сына ) информацию. Мой сын знает, что такое птица, и может понять, что утке присущи все свойства птицы плюс свойство "кряканье".

В объектно-ориентированных языках такая наследственная связь выражается в возможности одного класса наследовать другой. Таким образом, объектно-ориентированные языки позволяют создавать модели, более близкие к реальному миру ( а именно для этого они и созданы ), чем модели, построенные с помощью языков, не поддерживающих наследование. В С++ один класс может наследовать другой следующим образом:

class Student

{

} ;

class GraduateStudent : public Student

{

} ;

В этом примере GraduateStudent наследует все члены класса Student. Таким образом, GraduateStudent ЯВЛЯЕТСЯ студентом ( использование прописных букв должно подчеркнуть важность этого отношения ). Конечно, при этом GraduateStudent может также содержать уникальные, присущие именно ему члены.

_________________

233 стр. Глава 20. Наследование классов

►Зачем, нужно наследование...234

Наследование было включено в С++ по нескольким причинам. Конечно, основной из них была необходимость выражать связи между классами с помощью наследования ( к этому я ещё вернусь ). Менее важной целью было уменьшение размера исходного кода. Представьте себе, что у вас есть класс Student и вас попросили добавить новый класс под названием GraduateStudent. В этом случае наследование значительно уменьшит количество членов, которые вам придётся добавлять в класс. Всё, что вам действительно нужно в классе GraduateStudent, — это члены, которые будут описывать отличия между студентами и аспирантами.

¦¦¦¦¦¦¦¦¦¦«

Это потрясающе

Люди составляют обширные системы, чтобы было проще разбираться в том, что их окружает. Тузик является частным случаем собаки, которая является частным случаем собакообразных, которые входят в состав млекопитающих, и т.д. Так легче познавать мир.

Если использовать другой пример, можно сказать, что студент является человеком ( точнее, его частным случаем ). Как только это сказано, я уже знаю довольно много о студентах ( об американских студентах, естественно ). Я знаю, что они имеют номера социального страхования, что они слишком много смотрят телевизор и постоянно мечтают о сексе. Я знаю всё это потому, что это свойства всех людей. В С++ мы говорим, что класс student наследует класс Person. Кроме того, мы говорим, что Person является базовым классом для класса student. Наконец, мы говорим, что student ЯВЛЯЕТСЯ Person ( использование прописных букв — общепринятый метод отражения уникального типа связи; не я это придумал ). Эта терминология используется в С++ и других объектно-ориентированных языках программирования.

Заметьте, что хотя Student и ЯВЛЯЕТСЯ Person, обратное не верно. Person не ЯВЛЯЕТСЯ Student ( такое выражение следует трактовать в общем смысле, поскольку конкретный человек, конечно же, может оказаться студентом ). Существует много людей, которые являются членами класса Person и не являются членами класса student. Кроме того, класс student имеет средний балл, a Person его не имеет.

Свойство наследования транзитивно. Например, если я определю новый класс GraduateStudent как подкласс класса student, то он тоже будет наследником person. Это значит, что будет выполняться следующее: если GraduateStudent ЯВЛЯЕТСЯ Student и Student ЯВЛЯЕТСЯ Person, то GraduateStudent ЯВЛЯЕТСЯ Person.

»¦¦¦¦¦¦¦¦¦¦

Ещё один небольшой побочный эффект связан с изменениями, вносимыми в программное обеспечение. Предположим, что вы выполняете наследование некоторого существующего класса. Позже выясняется, что базовый класс работает не совсем так, как требуется порождённому классу, или что в нём имеется ошибка. Изменение базового класса может привести к неработоспособности всего кода, который использует этот базовый класс.

►Как наследуется класс...234

►Отношение СОДЕРЖИТ...238

Обратите внимание, что класс GraduateStudent включает в себя члены классов Student и Advisor, однако он включает их по-разному. Определяя данные-члены класса Advisor, вы знаете, что класс Student содержит внутри все данные-члены класса Advisor, но вы не можете сказать, что GraduateStudent ЯВЛЯЕТСЯ Advisor. Однако вы можете сказать, что GraduateStudent СОДЕРЖИТ Advisor. Какая разница между этим отношением и наследованием?

Используем в качестве примера автомобиль. Вы можете логически определить автомобиль как подкласс транспортных средств, а значит, он будет наследовать свойства остальных транспортных средств. С другой стороны, автомобиль содержит мотор. Если вы покупаете автомобиль, то покупаете и мотор ( если, конечно, вы не покупаете бывшую в употреблении машину там же, где я купил свою кучу металлолома ).

Если друзья пригласят вас приехать на воскресный пикник на новой машине и вы приедете на ней, никто не будет удивлён ( даже если вы явитесь на мотоцикле ), поскольку автомобиль ЯВЛЯЕТСЯ транспортным средством. Но если вы появитесь на своих двоих, неся в руках мотор, друзья решат, что вы попросту издеваетесь над ними, поскольку мотор не является транспортным средством, так как не имеет некоторых важных свойств, присущих транспортным средствам.

В аспекте программирования связь типа СОДЕРЖИТ достаточно очевидна. Разберём следующий пример:

class Vehicle

{

} ;

class Motor

{

} ;

class Car : public Vehicle

{

public :

Motor motor ;

} ;

void VehicleFn( Vehicle& v ) ;

void motorFn( Motor& m ) ;

_________________

238 стр. Часть 4. Наследование

int main( )

{

Car с ;

VehicleFn( с ) ; /* Так можно вызвать */

motorFn( c ) ; /* А так — нельзя */

motorFn( с.motor ) ; /* Нужно вот так */

return 0 ;

}

Вызов VehicleFn( с ) допустим, поскольку с ЯВЛЯЕТСЯ Vehicle. Вызов motorFn( с ) недопустим, поскольку с — не Motor, хотя он и содержит Motor. Если возникает необходимость передать функции только ту часть с, которая является мотором, это следует выразить явно: motorFn( с.motor ).

_________________

239 стр. Глава 20. Наследование классов

ОГЛАВЛЕНИЕ

В этой главе...

►Зачем нужен полиморфизм 243

►Как работает полиморфизм 245

►Когда функция не является виртуальной 246

►Виртуальные особенности 247

Количество и тип аргументов функции включены в её полное или, другими словами, расширенное имя. Это позволяет создавать в одной программе функции с одним и тем же именем ( если различаются их полные имена ):

void someFn( int )

void someFn( char* )

void someFn( char* , double )

Во всех трёх случаях функции имеют одинаковое короткое имя someFn( ). Полные имена всех трёх функций различаются: someFn( int ) отличается от someFn( char* ) и т.д. С++ решает, какую именно функцию нужно вызвать, рассматривая полные имена слева направо.

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

[Атас!]

Итак, функции-члены могут быть перегружены. При этом помимо количества и типов аргументов расширенное имя функции-члена содержит ещё и имя класса.

С появлением наследования возникает небольшая неувязка. Что, если функция-член базового класса имеет то же имя, что и функция-член подкласса? Попробуем разобраться с простым фрагментом кода:

class Student

{

public :

float calcTuition( ) ;

} ;

class GraduateStudent : public Student

{

public :

float calcTuition( ) ;

} ;

int main( int argcs , char* pArgs[ ] )

{

Student s ;

GraduateStudent gs ;

s.calcTuition( ) ; /* Вызывает Student::calcTuition( ) */

gs.calcTuition( ) ; /* Вызывает GraduateStudent::calcTuition( ) */

return 0 ;

}

_________________

240 стр. Часть 4. Наследование

Как и в любой ситуации с перегрузкой, когда программист обращается к calcTuition( ), С++ должен решить, какая именно функция calcTuition( ) вызывается. Если две функции отличаются типами аргументов, то нет никаких проблем. Даже если аргументы одинаковы, различий в именах класса достаточно, чтобы решить, какой именно вызов нужно осуществить, а значит, в этом примере нет ничего необычного. Вызов s.calcTuition( ) обращается к Student::calcTuition( ), поскольку s локально объявлена как Student, тогда как gs.calcTuition( ) обращается к GraduateStudent::calcTuition( ).

Но что, если класс объекта не может быть точно определён на этапе компиляции? Чтобы продемонстрировать подобную ситуацию, нужно просто немного изменить приведённую выше программу:

//

/* OverloadOverride — демонстрация невозможности */

/* точного определения типа */

//

#include

#include

#include

using namespace std ;

class Student

{

public :

/* Раскомментируйте одну из двух следующих строк; одна выполняет раннее связывание calcTuition( ), а вторая — позднее */

float calcTuition( )

/* virtual float calcTuition( ) */

{

cout << "Функция Student::calcTuition" << endl ;

return 0 ;

}

} ;

class GraduateStudent : public Student

{

public :

float calcTuition( )

{

cout << "Функция GraduateStudent::calcTuition"

<< endl ;

return 0 ;

}

} ;

void fn( Student& x )

{

x.calcTuition( ) ; /* Какая функция calcTuition( ) должна быть вызвана? */

}

_________________

241 стр. Глава 21. Знакомство с виртуальными функциями-членами: настоящие ли они

int main( int nNumberofArgs , char* pszArgs[ ] )

{

setlocale ( LC_ALL , ".1251" ) ; /* печать кириллицы */

/* Передача функции объекта базового класса */

Student s ;

fn( s ) ;

/* Передача функции объекта подкласса */

GraduateStudent gs ;

fn( gs ) ;

/* Пауза для того, чтобы посмотреть на результат работы программы */

system( "PAUSE" ) ; return 0 ;

}

Данная программа генерирует следующий вывод:

Функция Student::calcTuition

Функция Student::calcTuition

Press any key to continue...

На этот раз вместо прямого вызова calcTuition( ) осуществляется вызов через промежуточную функцию fn( ). Теперь всё зависит от того, какой аргумент передаётся fn( ), поскольку х может быть как Student, так и GraduateStudent — ведь GraduateSudent ЯВЛЯЕТСЯ Student!

«Если вы этого не знали, это вовсе не говорит о том, что вы ЯВЛЯЕТЕСЬ "чайником". Это значит, что вы не читали главу 20 , "Наследование классов".»

[Помни!]

Аргумент х, передаваемый fn( ), для экономии места и времени объявлен как ссылка на объект класса Student. Если бы этот аргумент передавался по значению, С++ пришлось бы при каждом вызове fn( ) конструировать новый объект Student. В зависимости от вида класса Student и количества вызовов fn( ) в итоге это может занять много времени, тогда как при вызове fn( Student& ) или fn( Student* ) передаётся только адрес. Если вы не поняли, о чём я говорю, перечитайте главу 18, "Копирующий конструктор".

Было бы неплохо, если бы строка х.calcTuition( ) вызывала Student::calcTuition( ), когда х является объектом класса Student, и GraduateSudent::calcTuition( ), когда х является объектом класса GraduateStudent. Если бы С++ был настолько "сообразителен", это было бы действительно здорово! Почему? Об этом вы узнаете далее в главе.

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

В данном случае объявленный тип аргумента функции fn( ) не полностью описывает требования к функции. Хотя аргумент и объявлен как Student, он может оказаться также и GraduateStudent. Окончательное решение можно принять, только когда программа выполняется ( это называется "на этапе выполнения" ). И только когда функция fn( ) уже вызвана, С++ может посмотреть на тип аргумента и решить, какая именно функция-член должна вызываться: из класса Student или из GraduateStudent.

_________________

242 стр. Часть 4. Наследование

«Типы аргументов, с которыми вы сталкивались до этого времени, называются объявленными, или типами этапа компиляции. Объявленным типом аргумента х в любом случае является Student, поскольку так написано в объявлении функции fn( ). Другой, текущий, тип называется типом этапа выполнения. В случае с примером функции fn( ) типом этапа выполнения аргумента х является Student, если fn( ) вызывается с s, и GraduateStudent, когда fn( ) вызывается с gs.»

[Советы]

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

Перегрузка функции базового класса называется переопределением ( overriding ) функции базового класса. Такое новое название используется, чтобы отличать этот более сложный случай от нормальной перегрузки.

►Зачем нужен полиморфизм...243

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

«Языки, которые поддерживают классы, но не поддерживают полиморфизм, называются объектно-основанными. К таким языкам относится, например, Ada.»

[Советы]

Без полиморфизма от наследования было бы мало толку. Позвольте привести ещё один пример, чтобы вы поняли, почему это так. Представим себе, что я написал действительно сложную программу, использующую некий класс, который называется — не будем далеко ходить за примером — Student. После нескольких месяцев разработки, кодирования и тестирования я выставляю эту программу на всеобщее обозрение, чтобы услышать восторженные отзывы и критику от своих коллег. ( Программа настолько "крута", что уже заходит речь о передаче мне контрольного пакета акций Microsoft... но не будем опережать события. )

Проходит время, и мой босс просит добавить в программу возможность работы с аспирантами, которые хотя и очень похожи, но всё-таки отличаются от обычных студентов ( правда, аспиранты думают, что они совсем не похожи на студентов! ). Мой босс не знает и не интересуется тем, что где-то глубоко в программе функция someFunction( ) вызывает функцию-член calcTuition( ) ( такая уж работа у босса — ни о чём не думать и не волноваться... ).

void someFunction( Student& s )

{

/* ...то, что эта функция должна делать... */

s.calcTuition( ) ;

/* ...функция продолжается... */

}

Если бы С++ не поддерживал позднее связывание, мне бы пришлось отредактировать функцию someFunction( ) приблизительно так, как показано ниже, и добавить её в класс GraduateStudent.

_________________

243 стр. Глава 21. Знакомство с виртуальными функциями-членами: настоящие ли они

#define STUDENT 1

#define GRADUATESTUDENT 2

void someFunction( Student& s )

{

/* ...то, что эта функция должна делать... Добавим тип члена, который будет индицировать текущий тип объекта */

switch ( s.type )

{

case STUDENT :

s.Student::calcTuition( ) ;

break ;

case GRADUATESTUDENT :

s.GraduateStudent::calcTuition( ) ;

break ;

}

/* ...функция продолжается... */

}

Мне бы пришлось добавить в класс переменную type. После этого я был бы вынужден добавить присвоения type = STUDENT к конструктору Student и type = GRADUATESTUDENT к конструктору GraduateStudent. Значение переменной type отражало бы текущий тип объекта s. Затем мне пришлось бы добавить проверяющие команды, показанные в приведённом выше фрагменте программы, везде, где вызываются переопределяемые функции.

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

Во-вторых, я должен изменить ( читай — сломать ) код, который был отлажен и работал, а местами был довольно запутан. Редактирование может занять много времени и стать довольно скучной процедурой, что обычно ослабляет моё внимание. Любое изменение может оказаться ошибочным и конфликтовать с существующим кодом. Кто знает?..

И наконец, после того как я завершу редактирование, отладку и тестирование программы, я должен буду поддерживать две её версии ( если, конечно, не перестану поддерживать исходную ). Это означает наличие двух потенциальных источников проблем в случае выявления ошибок и необходимость отдельной системы систематизации ( как вам такая тавтология? ), чтобы содержать всё это в порядке.

А теперь представьте себе, что случится, когда мой босс захочет добавить ещё один класс ( босс — он такой: на всё способен... ). Мне придётся не только повторить весь процесс сначала, а поддерживать три версии программы!

При наличии полиморфизма всё, что потребуется сделать, — это добавить новый подкласс и перекомпилировать программу. В принципе мне может понадобиться изменить сам базовый класс, но только его и только в одном месте. Изменения в коде приложения будут сводиться к минимуму.

На некотором философском уровне есть ещё более важные причины для полиморфизма. Помните, как я готовил закуски в микроволновой печи? Можно сказать, что я действовал по принципу позднего связывания. Рецепт был таким: разогрейте закуску в печи. В нём не было сказано: если печь микроволновая, сделай так, а если конвекционная — эдак. В рецепте ( читай — коде ) предполагалось, что я ( читай — тот, кто осуществляет позднее связывание ) сам решу, какой именно разогрев ( функцию-член ) выбрать, в зависимости от типа используемой печи ( отдельного экземпляра класса Oven ) или её вариаций ( подклассов ), например таких, как микроволновая печь ( Microvawe ). Так думают люди, и так же создаются языки программирования: чтобы дать людям возможность, не изменяя образа мыслей, создавать более точные модели реального мира.

_________________

244 стр. Часть 4. Наследование

►Как работает полиморфизм...245

Любой язык программирования может поддерживать раннее либо позднее связывание. Старые языки типа С в основном поддерживают раннее связывание. Более поздние языки, наподобие Java, поддерживают позднее связывание. С++ же поддерживает оба типа связывания.

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

Последняя причина в том, что достаточно полезной для программиста оказывается возможность определить, будет ли переопределяться некоторая функция в будущем или нет. Этого оказалось достаточно, чтобы в С# Microsoft позволила программистам указывать, что некоторая функция будет непереопределимой ( по умолчанию все функции переопределимы ).

Чтобы сделать функцию-член полиморфной, программист на С++ должен пометить её ключевым словом virtual так, как это показано ниже.

class Student

{

public :

/* Раскомментируйте одну из двух следующих строк; одна выполняет раннее связывание calcTuition( ), а вторая — позднее */

virtual float calcTuition( )

{

cout << "Функция Student::calcTuition" << endl ;

return 0 ;

}

} ;

Ключевое слово virtual сообщает С++ о том, что calcTuition( ) является полиморфной функцией-членом. Это так называемое виртуальное объявление calcTuition( ) означает, что вызовы данной функции-члена будут связаны позже, если есть хоть какие-то сомнения по поводу типа объекта, для которого будет вызываться функция calcTuition( ) на этапе выполнения.

В приведённой ранее демонстрационной программе OverloadOverride calcTuition( ) вызывается через промежуточную функцию fn( ). Когда функции fn( ) передаётся объект базового класса, она вызывает функцию Student::calcTuition( ). Но когда функции передаётся объект подкласса, этот же вызов обращается к функции GraduateStudent::calcTuition( ).

Запуск программы приведёт к выводу на экран таких строк:

Функция Student::calcTuition

Функция GraduateStudent::calcTuition

Press any key to continue...

«Если вы уже освоились с отладчиком вашей среды С++, настоятельно рекомендую выполнить этот пример в пошаговом режиме.»

[Технические подробности]

_________________

245 стр. Глава 21. Знакомство с виртуальными функциями-членами: настоящие ли они

«Достаточно объявить функцию виртуальной только в базовом классе. Виртуальность наследуется подклассами автоматически. Однако в этой книге я следую стандарту кодирования, в соответствии с которым функции объявляются виртуальными везде.»

[Советы]

«Обратитесь к программе PolymorphicNachos.срр на прилагаемом компакт-диске, чтобы лучше ознакомиться с полиморфизмом.»

[Диск]

►Когда фунция не являтся виртуальной...246

Даже если вы считаете, что некоторая функция вызывается с использованием позднего связывания, это отнюдь не означает, что так и есть на самом деле. Если она не объявлена с теми же аргументами в подклассах, то она не будет переопределяться, независимо от того, объявили ли вы её виртуальной или нет.

В правиле об идентичности объявления есть только одно исключение, которое состоит в том, что если функция-член базового класса возвращает указатель или ссылку на объект базового класса, то переопределяемая функция-член может возвращать указатель или ссылку на объект подкласса. Другими словами, приведённая ниже программа допустима.

class Base

{

public :

/* Возвращает копию текущего объекта */

Base* makeACopy( )

{

/* ...делает всё, что нужно для создания копии */

}

} ;

class Subclass : public Base

{

public :

/* Возвращает копию текущего объекта */

Subclass* makeACopy( )

{

/* ...Делает всё, что нужно для создания копии */

}

} ;

void fn( BaseClass& bс )

{

BaseClass* pCopy = bс.makeACopy( ) ;

/* Функция продолжается... */

}

С практической точки зрения всё естественно: функция копирования makeCopy( ) должна возвращать указатель на объект типа Subclass, даже если она переопределяет Base::makeCopy( ).

_________________

246 стр. Часть 4. Наследование

►Виртуальные особенности...247

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

Во-вторых, при указании имени класса в вызове функция будет компилироваться с использованием раннего связывания независимо от того, объявлена она виртуальной или нет.

Например, приведённый ниже вызов обращается к Base::fn( ), поскольку так указал программист, независимо от того, объявлена fn( ) виртуальной или нет.

void test( Base& b )

{

b.base::fn( ) ;

/* Этот вызов не использует позднего связывания */

}

Кроме того, виртуальная функция не может быть встроенной. Чтобы подставить функцию на место её вызова, компилятор должен знать её на этапе компиляции. Таким образом, независимо от способа описания виртуальные функции-члены рассматриваются как не встроенные.

И наконец, конструкторы не могут быть виртуальными, поскольку во время работы конструктора не существует завершённого объекта какого-либо определённого типа. В момент вызова конструктора память, выделенная для объекта, является просто аморфной массой. И только после окончания работы конструктора объект становится экземпляром класса в полном смысле этого слова.

В отличие от конструктора, деструктор может быть объявлен виртуальным. Более того, если он не объявлен виртуальным, вы рискуете столкнуться с неправильной ликвидацией объекта, как, например, в следующей ситуации:

class Base

{

public :

~Base( ) ;

} ;

class SubClass : public Base

{

public :

~SubClass( ) ;

} ;

void finishWithObject( Base* pHeapObject )

{

delete pHeapObject ; /* Здесь вызывается ~Base( ) независимо от типа указателя pHeapObject */

}

Если указатель, передаваемый функции finishWithObject( ), на самом деле указывает на объект SubСlass, деструктор Subclass всё равно вызван не будет: поскольку он не был объявлен виртуальным, используется раннее связывание. Однако, если объявить деструктор виртуальным, проблема будет решена.

А если вы не хотите объявлять деструктор виртуальным? Тому может быть только одна причина: виртуальные функции несколько увеличивают размер объекта. Когда программист определяет первую виртуальную функцию в классе, С++ прибавляет к классу дополнительный скрытый указатель — именно один указатель на класс, а не для каждой виртуальной функции.

_________________

247 стр. Глава 21. Знакомство с виртуальными функциями-членами: настоящие ли они

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

■■■

■ класс не содержит много данных, так что даже один указатель существенно увеличивает его размер;

■ вы намерены создать большое количество объектов, так что один указатель, умноженный на количество объектов, даст существенный перерасход памяти.

■■■

Если выполняются два перечисленных условия, а в классе нет виртуальных функций — это единственное основание не делать деструктор виртуальным.

«Лучше всегда объявлять деструкторы виртуальными, даже если ваш класс не наследуется ( пока не наследуется! ): ведь никогда не известно, в какой момент появится некто ( может, это будете вы сами ), желающий воспользоваться вашим классом как базовым для своего собственного класса. Если вы не объявили деструктор виртуальным, обязательно документируйте это!»

[Атас!]

_________________

248 стр. Часть 4. Наследование

ОГЛАВЛЕНИЕ

В этой главе...

►Разложение 249

►Реализация абстрактных классов 253

►Разделение исходного кода С++ 259

Концепция наследования помогает в достижении многих целей; например, благодаря ему я плачу за обучение моего сына. Оно помогает избежать повторения кода и сократить время, затрачиваемое на написание программ. Благодаря наследованию можно повторно использовать уже существующий код в новых программах, переопределяя функции.

Главное преимущество наследования — возможность указывать тип взаимосвязи между классами. Это так называемая взаимосвязь типа ЯВЛЯЕТСЯ: микроволновая печь ЯВЛЯЕТСЯ печью и т.д.

Разложение — это прекрасный способ создания правильных связей. К примеру, связь микроволновой печи с конвекционной печью кажется естественной. Утверждение же о том, что микроволновая печь является особым типом тостера, скорее всего, вас несколько насторожит. Конечно, оба эти прибора нагревают, оба используют электричество и оба находятся на кухне, но на этом сходство заканчивается — микроволновая печь не готовит тосты.

Процедура определения классов, свойственных данной проблеме, и задания корректных связей между этими классами известна под названием разложение ( factoring ) ( это слово относится к арифметике, с которой вы мучились в средней школе; помните, как вы занимались разложением числа на простые множители: 12 равно 2, умноженное на 2 и на 3... ).

►Разложение...249

Чтобы увидеть, как использовать наследование для упрощения ваших программ, рассмотрим простейшее банковское приложение.

«Предположим, что нам надо написать простейшую банковскую программу. ( Описание этой программы имеется на прилагаемом компакт-диске. )»

[Диск]

Я мог бы до посинения рассказывать об этих классах, однако, к счастью, объектно-ориентированные программисты придумали довольно наглядный и краткий путь описания классов. Классы Checking и Savings показаны на рис. 22.1.

Для того чтобы правильно понять этот рисунок, необходимо знать несколько правил.

■■■

■ Большой прямоугольник — это класс. Имя класса написано сверху.

■ Имена в меньших прямоугольниках — это функции-члены.

_________________

249 стр. Глава 22. Разложение классов

Рис. 22.1. Независимые классы Checking и Savings

■ Имена не в прямоугольниках — это данные-члены.

■ Имена, которые выступают за пределы прямоугольника, ограничивающего класс, являются открытыми; к этим членам могут обращаться функции, не являющиеся членами класса или его наследников. Члены, которые находятся полностью внутри прямоугольника, недоступны снаружи класса.

■ Толстая стрелка обозначает связь типа ЯВЛЯЕТСЯ.

■ Тонкая стрелка обозначает связь типа СОДЕРЖИТ.

■■■

Автомобиль ЯВЛЯЕТСЯ транспортным средством и при этом СОДЕРЖИТ мотор.

На рис. 22.1 вы можете увидеть, что классы Checking и Savings имеют много общего. Например, оба класса включают функции-члены withdrawal( ) и deposit( ). Поскольку эти классы не идентичны, они, конечно же, должны оставаться раздельными ( в реальном банковском приложении эти два класса отличались бы гораздо существеннее ). Однако мы должны найти способ избежать дублирования.

Можно сделать так, чтобы один из этих классов наследовал другой. Класс Savings имеет больше членов, чем Checking, так что мы могли бы унаследовать Savings от Checking. Такой путь реализации этих классов приведён на рис. 22.2. Класс Savings наследует все члены класса Checking. Кроме того, в классе добавлен член noWithdrawal и переопределена функция withdrawal( ). Эта функция переопределена, поскольку правила снятия денег со сберегательного счёта отличаются от правил снятия с чекового счёта ( хотя меня эти правила вообще не касаются, поскольку у меня нет денег, которые можно было бы снять со счёта ).

Хотя наследование Savings от Checking и сберегает наш труд, нас оно не очень удовлетворяет. Главная проблема состоит в том, что оно искажает истинное положение вещей. При таком использовании наследования подразумевается, что счёт Savings является специальным случаем счёта Checking.

"Ну и что? — скажете вы. — Такое наследование работает и сохраняет нам силы и время". Это, конечно, так, но мои предупреждения — это не просто сотрясание воздуха. Такие искажения запутывают программиста уже и сейчас, но ещё больше будут мешать в дальнейшем. Однажды программист, не знакомый с нашими "приёмчиками", будет читать нашу программу, пытаясь понять, что же она делает. Вводящие в заблуждение представления очень трудны для понимания и ведения программы.

_________________

250 стр. Часть 4. Наследование

Рис. 22.2. Класс Savings реализован как подкласс checking

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

Такое изменение политики банка можно легко отразить в классе Checking. Все, что нужно сделать, — это добавить новый член в класс Checking, чтобы следить за минимальным балансом в течение месяца. Назовём его minimumBalance.

Однако теперь возникает проблема. Если Savings наследует Checking, значит, Savings тоже получает этот член. При этом он не используется, поскольку в сберегательных счетах минимальный баланс не нужен. Так что дополнительный член просто присутствует в классе. Итак, каждый объект чекового счёта имеет дополнительный член minimumBalance. Один дополнительный член — это не так уж и много, но он вносит свою лепту в общую неразбериху.

Такие изменения имеют свойство накапливаться. Сегодня это один член, а завтра — изменённая функция-член. В результате объекты класса Savings будут содержать множество дополнительных данных, которые нужны исключительно в классе Checking. Если вы будете невнимательны, изменения в классе Checking могут перейти к классу Savings и привести к его некорректной работе.

Далее банк решил изменить правила работы с чековыми счетами. Для этого вам требуется изменить некоторые функции в Checking. Эти изменения автоматически перейдут в подклассы. Предположим, например, что банк решил начислять дополнительные проценты по чековым вкладам ( ну, бывают же чудеса... ) — но главное чудо будет в том, что при нашей системе наследования эти же проценты будут начисляться и на сберегательных счетах.

Как же этого избежать? Если поменять местами Checking и Savings, проблема не исчезнет. Нужен некий третий класс ( назовём его Account ), который будет воплощать в себе всё то общее, что есть у Checking и Savings. Такая связь приведена на рис. 22.3.

Каким образом создание нового класса Account решит наши проблемы? Во-первых, такой класс сделает более аккуратным описание реального мира ( чем бы он ни являлся ). В нашей концепции мира ( по крайней мере, в моей ) действительно есть нечто, что можно назвать счётом.

_________________

251 стр. Глава 22. Разложение классов

Сберегательные и чековые счета являются частным случаем этой более фундаментальной концепции.

Кроме того, класс Savings отмежёвывается от изменений в классе Checking ( и наоборот ). Если банк решит провести фундаментальные изменения во всех счетах, можно просто изменить класс Account, и все подклассы автоматически унаследуют эти изменения. Но если банк изменит политику только для чековых счетов, можно просто модифицировать класс Checking, не изменяя при этом класс Savings.

Такая процедура отбора общих свойств похожих классов и называется разложением. Этот процесс очень важен в объектно-ориентированных языках по причинам, которые были приведены выше, а также потому, что разложение помогает избавиться от избыточности. Позвольте мне повториться: избыточность — это не просто плохо, это очень плохо...

Рис. 22.3. Классы checking и Savings, базирующиеся на классе Account

«Разложение будет обоснованным только в том случае, когда взаимосвязь, представляемая наследованием, соответствует реальности. Выделение общих свойств класса Mouse и Joystick и разложение их на "множители" вполне допустимо. И мышь и джойстик являются аппаратными устройствами позиционирования. Но выделение общих свойств классов Mouse и Display ничем не обосновано.»

[Атас!]

Разложение может давать ( и обычно даёт ) результат на нескольких уровнях абстракции. Например, программа, написанная для более "продвинутого" банка, может иметь структуру классов, показанную на рис. 22.4.

Из этого рисунка видно, что между классами Checking и Savings и более общим классом Account вставлен ещё один класс. Он называется Conventional и объединяет в себе особенности обычных счетов. Другие типы счетов, например счета ценных бумаг и биржевые счета, также объявляются как отдельные классы.

Такая многослойная структура классов весьма распространена и даже желательна ( пока отношения, которые она представляет, отражают реальность. Однако не забывайте, что для любого заданного набора классов не существует одной единственно правильной иерархии классов ).

_________________

252 стр. Часть 4. Наследование

Рис. 22.4. Развитая структура банковских счетов

Представим, что банк позволяет держателям счетов удаленно обращаться к чековым счетам и счетам ценных бумаг. Снимать же деньги с других типов счетов можно только в банке. Хотя структура классов, приведённая на рис. 22.4, выглядит естественной, в данных условиях более приемлема другая структура ( рис. 22.5 ). Программист должен решить, какая структура классов лучше всего подходит к данным условиям, и стремиться к наиболее ясному и естественному представлению.

Рис. 22.5. Альтернативная иерархия классов

►Реализация абстрактных классов...253

►Разделение исходного кода С++...259