Стефан Дэвис - С++ для чайников .

class Account

{

/* То же, что и раньше, но нет функции withdrawal( ) */

} ;

class Savings : public Account

{

public :

virtual void withdrawal( float amnt ) ;

} ;

void fn( Account *pAcс )

{

/* снять некоторую сумму */

pAcc -> withdrawal( 100.00f ) ;

/* Этот вызов недопустим, поскольку withdrawal( )не является членом класса Account */

}

int main( )

{

Savings s ; /* Открыть счёт */

fn( & s ) ;

/* Продолжение программы */

}

Представьте себе, что вы открываете сберегательный счёт s . Затем вы передаёте адрес этого счёта функции fn( ) , которая пытается выполнить функцию withdrawal( ) . Однако, поскольку функция withdrawal( ) не член класса Account , компилятор сгенерирует сообщение об ошибке.

Взгляните, как чисто виртуальная функция помогает решить эту проблему. Ниже представлена та же ситуация с абстрактным классом Account :

class Account

{

/* Почти то же, что и в предыдущей программе, однако функция withdrawal( ) определена */

virtual void withdrawal( float amnt ) = 0 ;

} ;

class Savings : public Account

{

public :

virtual void withdrawal( float amnt ) ;

} ;

void fn( Account *pAcc )

{

/* Снять некоторую сумму. Теперь этот код будет работать */

рАсс -> withdrawal( 100.00f ) ;

}

int main( )

{

Savings s ; /* Открыть счёт */

fn( & s ) ;

/* Продолжение программы */

}

_________________

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

Ситуация та же, но теперь класс Account содержит функцию-член withdrawal( ) . Поэтому, когда компилятор проверяет, определена ли функция pAcc -> withdrawal( ) , он видит ожидаемое определение Account::withdrawal( ) . Компилятор счастлив. Вы счастливы. А значит, и я тоже счастлив. ( Честно говоря, для того чтобы сделать меня счастливым, достаточно футбола и холодного пива. )

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

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

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

«Процесс объединения раздельно скомпилированных модулей в единый выполнимый файл называется компоновкой, илисвязыванием ( linking ) — линкованием.»

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

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

«Инкапсуляция представляет собой одно из преимуществ объектно-ориентированного программирования.»

[ Помни! ]

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

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

И наконец, вопрос времени. Компилятору наподобие Visual С++ .NET или Dev-C++ не требуется много времени, чтобы скомпилировать примеры из этой книги. Однако серьёзные коммерческие программы состоят из миллионов строк кода, и полная компиляция и сборка таких программ может потребовать больше суток машинного времени. Вряд ли программист сможет нормально работать, если после внесения любого изменения ему потребуются сутки на сборку приложения. Гораздо быстрее оказывается перекомпилировать только один файл с внесёнными изменениями, после чего быстро скомпоновать приложение из уже скомпилированных модулей.

_________________

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

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

Рассмотрим простую программу SeparateModules , которая состоит из модулей, содержащих класс Student , его подкласс GraduateStudent и модуль с функцией main( ) для тестирования этих классов.

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

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

[ Советы ]

Полученный в результате файл Student.h выглядит следующим образом.

/* Student — базовый класс */

#ifndef _STUDENT_

#define _STUDENT_

namespace Schools

{

class Student

{

public :

Student( char* pszName , int nID ) ;

virtual char* display( ) ;

protected :

/* Имя студента */

char* pszName ;

int nID ;

} ;

}