Программирование. Принципы и практика использования C++ Исправленное издание
вернуться

Страуструп Бьерн
Шрифт:

Остается одна проблема: что произойдет, если мы забудем использовать функцию-член

add_day
? Что произойдет, если кто-то решит непосредственно изменить месяц? Оказывается, мы забыли предусмотреть возможности для выполнения этой операции.

Date birthday(1960,12,31); // 31 декабря 1960 года

++birthday.d; // Ой! Неправильная дата

Date today(1970,2,3);

today.m = 14; // Ой! Неправильная дата

// today.m == 14

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

Такие размышления приводят к выводу, что представление типа

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

// простой типа Date (управление доступом)

class Date {

int y, m, d; // год, месяц, день

public:

Date(int y, int m, int d); // проверка и инициализация даты

void add_day(int n); // увеличение объекта типа Date на n дней

int month { return m; }

int day { return d; }

int year { return y; }

};

Этот класс можно использовать следующим образом:

Date birthday(1970, 12, 30); // OK

birthday.m = 14; // ошибка: Date::m — закрытый член

cout << birthday.month << endl; // доступ к переменной m

Понятие “правильный объект типа
Date
” — важная разновидность идеи о корректном значении. Мы пытаемся разработать наши типы так, чтобы их значения гарантированно были корректными; иначе говоря, скрываем представление, предусматриваем конструктор, создающий только корректные объекты, и разрабатываем все функции-члены так, чтобы они получали и возвращали только корректные значения. Значение объекта часто называют состоянием (state), а корректное значение — корректным состоянием объекта.

В качестве альтернативы можно проверять корректность объекта при каждой попытке его использования или просто надеяться на то, что никто никогда не создаст ни одного некорректного значения. Опыт показывает, что такие надежды могут привести к “очень хорошим” программам. Однако создание таких программ, которые иногда выдают ошибочные результаты, а порой вообще приводят к аварийному отказу, не принесет вам профессионального признания. Мы предпочитаем писать программы, корректность которых можно продемонстрировать.

Правило, регламентирующее смысл корректного значения, называют инвариантом (invariant). Инвариант для класса
Date
(“Объект класса
Date
должен представлять дату в прошлом, настоящем и будущем времени”) необычайно трудно сформулировать точно: вспомните о високосных годах, григорианском календаре, часовых поясах и т.п. Однако для простых и реалистичных ситуаций можно написать класс
Date
. Например, если мы инициализируем интернет-протоколы, нас не должны беспокоить ни григорианский, ни юлианский календари, ни календарь племени майя. Если мы не можем придумать хороший инвариант, то, вероятно, имеют место простые данные. В таких случаях следует использовать обычные структуры
struct
.

9.4.4. Определение функций-членов

До сих пор мы смотрели на класс

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

// простой класс Date (детали реализации будут рассмотрены позднее)

class Date {

public:

Date(int y, int m, int d); // проверка и инициализация даты

void add_day(int n); // увеличивает объект класса Date на n дней

int month;

// ...

private:

int y, m, d; // лет, месяцев, дней

};

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