Читаем C++ полностью

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

class temporary (* ... *); class employee (* ... *); class secretary : employee (* ... *);

// Альтернатива: class temporary_secretary : secretary (* temporary temp; ... *); class consultant : employee (* temporary temp; ... *);

Это выглядит неэлегантно и страдает как раз от тех пролем, для преодоления которых были изобретены производные классы. Например, поскольку consultant не является произвоным от temporary, consultant'а нельзя помещать с список врменных служащих (temporary employee), не написав специальный код. Однако во многих полезных программах этот метод успешно используется.

<p>7.2.6 Конструкторы и деструкторы</p>

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

class base (* // ... public: base(char* n, short t); ~base; *);

class derived : public base (* base m; public: derived(char* n); ~derived; *);

Параметры конструктора базового класса специфицируются в определении конструктора производного класса. В этом смысле базовый класс работает точно также, как неименованный член производного класса (см. #5.5.4). Например:

derived::derived(char* n) : (n,10), m(«member»,123) (* // ... *)

Объекты класса конструируются снизу вверх: сначала базвый, потом члены, а потом сам производный класс. Уничтожаются они в обратном порядке: сначала сам производный класс, потом члены а потом базовый.

<p>7.2.7 Поля типа</p>

Чтобы использовать производные классы не просто как удобную сокращенную запись в описаниях, надо разрешить следющую проблему: Если задан указатель типа base*, какому проиводному типу в действительности принадлежит указываемый обект? Есть три основных способа решения этой проблемы:

1. Обеспечить, чтобы всегда указывались только объекты одного типа (#7.3.3),

2. Поместить в базовый класс поле типа, которое смогут просматривать функции и

3. Использовать виртуальные функции (#7.2.8).

Обыкновенно указатели на базовые классы используются при разработке контейнерных (или вмещающих) классов: множество, вектор, список и т.п. В этом случае решение 1 дает однородные списки, то есть списки объектов одного типа. Решения 2 и 3 можно использовать для построения неоднородных списков, то есть списков объектов (указателей на объекты) нескольких раличных типов. Решение 3 – это специальный вариант решения 2 с гарантией типа.

Давайте сначала исследуем простое решение с помощью поля типа, то есть решение 2. Пример со служащими и менеджерами можно было бы переопределить так:

enum empl_type (* M, E *);

struct employee (* empl_type type; employee* next; char* name; short department; // ... *);

struct manager : employee (* employee* group; short level; // уровень *);

Имея это, мы можем теперь написать функцию, которая пчатает информацию о каждом служащем:

void print_employee(employee* e) (* switch (e-»type) (* case E: cout «„ e-“name „„ „\t“ „„ e-“department „„ „\n“; // ... break; case M: cout „« e-“name «« «\t“ «« e-“department «« «\n“; // ... manager* p = (manager*)e; cout «« " уровень " «« p-“level «« «\n“; // ... break;

*) *)

и воспользоваться ею для того, чтобы напечатать список служащих:

void f (* for (; ll; ll=ll-»next) print_employee(ll); *)

Это прекрасно работает,особенно в небольшой программе, написанной одним человеком, но имеет тот коренной недостаток, что неконтролируемым компилятором образом зависит от того, как программист работает с типами. В больших программах это обычно приводит к ошибкам двух видов. Первый – это невыполнние проверки поля типа, второй – когда не все случаи case пмещаются в переключатель switch, как в предыдущем примере. Оба избежать достаточно легко , когда программу сначала пишут на бумаге, но при модификации нетривиальной программы, осбенно написанной другим человеком, очень трудно избежать как того, так и другого. Часто от этих сложностей становится труднее уберечься из-за того, что функции вроде print часто бывают организованы так, чтобы пользоваться общностью класов, с которыми они работают. Например:

void print_employee(employee* e) (* cout «„ e-“name „„ „\t“ „„ e-“department „« «\n“; // ... if (e-“type == M) (* manager* p = (manager*)e; cout «« " уровень " «« p-“level «« «\n“; // ... *) *)

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

<p>7.2.8 Виртуальные функции</p>
Перейти на страницу:

Похожие книги

Основы программирования в Linux
Основы программирования в Linux

В четвертом издании популярного руководства даны основы программирования в операционной системе Linux. Рассмотрены: использование библиотек C/C++ и стан­дартных средств разработки, организация системных вызовов, файловый ввод/вывод, взаимодействие процессов, программирование средствами командной оболочки, создание графических пользовательских интерфейсов с помощью инструментальных средств GTK+ или Qt, применение сокетов и др. Описана компиляция программ, их компоновка c библиотеками и работа с терминальным вводом/выводом. Даны приемы написания приложений в средах GNOME® и KDE®, хранения данных с использованием СУБД MySQL® и отладки программ. Книга хорошо структурирована, что делает обучение легким и быстрым. Для начинающих Linux-программистов

Нейл Мэтью , Ричард Стоунс , Татьяна Коротяева

ОС и Сети / Программирование / Книги по IT
97 этюдов для архитекторов программных систем
97 этюдов для архитекторов программных систем

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

Билл де Ора , Майкл Хайгард , Нил Форд

Программирование, программы, базы данных / Базы данных / Программирование / Книги по IT
Программист-прагматик. Путь от подмастерья к мастеру
Программист-прагматик. Путь от подмастерья к мастеру

Находясь на переднем крае программирования, книга "Программист-прагматик. Путь от подмастерья к мастеру" абстрагируется от всевозрастающей специализации и технических тонкостей разработки программ на современном уровне, чтобы исследовать суть процесса – требования к работоспособной и поддерживаемой программе, приводящей пользователей в восторг. Книга охватывает различные темы – от личной ответственности и карьерного роста до архитектурных методик, придающих программам гибкость и простоту в адаптации и повторном использовании.Прочитав эту книгу, вы научитесь:Бороться с недостатками программного обеспечения;Избегать ловушек, связанных с дублированием знания;Создавать гибкие, динамичные и адаптируемые программы;Избегать программирования в расчете на совпадение;Защищать вашу программу при помощи контрактов, утверждений и исключений;Собирать реальные требования;Осуществлять безжалостное и эффективное тестирование;Приводить в восторг ваших пользователей;Формировать команды из программистов-прагматиков и с помощью автоматизации делать ваши разработки более точными.

А. Алексашин , Дэвид Томас , Эндрю Хант

Программирование / Книги по IT