Программирование

++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;               // лет, месяцев, дней

};