Во-вторых, номер месяца или дня может быть указан неверно:
Date(2, 20, 1995); // Должно быть “3, 30”, а не “2, 20”
(Последний пример может показаться надуманным, но вспомните, что на клавиатуре «2» находится рядом с «3». Такие опечатки случаются сплошь и рядом.)
Многих ошибок можно избежать за счет введения новых типов. Система контроля типов – ваш первый союзник в деле предотвращения компилируемости нежелательного кода. В данном случае мы можем ввести простые типы-обертки, чтобы различать дни, месяцы и годы, затем использовать их в конструкторе Date:
struct Day { struct Month { struct Year {
explicit Day(int d) explicit Month(int m) explicit Year(int y)
: val(d) {} : val(m) {} : val(y) {}
int val; int val; int val;
}; }; };
class Date {
public:
Date(const Month& m, const Day& d, const Year& y(;
...
};
Date d(30, 3, 1995); // ошибка! неправильные типы
Date d(Day(30), Month(3), Year(1995); // ошибка! неправильные типы
Date d(Month(3), Day(30), Year(1995)); // порядок, типы корректны
Еще лучше сделать Day, Month и Year полноценными классами, инкапсулирующими свои данные (см. правило 22). Но даже применение простых структур наглядно демонстрирует, что разумное использование новых типов способно эффективно предотвратить ошибки при использовании интерфейсов.
После того как определены правильные типы, иногда имеет смысл ограничить множество принимаемых ими значений. Например, есть только 12 допустимых значений месяцев, что и должен отразить тип Month. Один из способов сделать это – применить перечисление (enum) для представления месяца. Но перечисления не так безопасны по отношению к типам, как хотелось бы. Например, перечисления могут быть использованы как значения типа int (см. правило 2). Более безопасное решение – определить набор допустимых месяцев:
class Month {
public:
static Month Jan() {return Month(1);} // функции возвращают все
static Month Feb() {return Month(2);} // допустимые значения Month.
... // Cм. ниже, почему это функции,
static Month Dec() {return Month(12);} // а не объекты
... // прочие функции-члены
private:
explicit Month(int m); // предотвращает создание новых
// значений Month
... // специфичные для месяца данные
};
Date d(Month::Mar(), Day(30), Year(1995));
Идея применения функций вместо объектов для представления месяцев может показаться вам необычной. Но вспомните о ненадежности инициализации нелокальных статических объектов. Правило 4 поможет освежить вашу память.
Другой способ предотвратить вероятные ошибки клиентов – ограничить множество разрешенных для типа операций. Общий способ установить ограничения – добавить const. Например, в правиле 3 объясняется, как добавление модификатора const к типу значения, возвращаемого функцией operator*, может предотвратить следующую ошибку клиента:
if(a *b = c)... // имелось в виду сравнение
Фактически это пример другого общего правила облегчения правильного использования типов и усложнения неправильного их использования: поведение ваших типов должно быть согласовано с поведением встроенных типов (кроме некоторых исключительных случаев). Клиенты уже знают, как должны себя вести типы вроде int, поэтому вы должны стараться, чтобы ваши типы по возможности вели себя аналогично. Например, присваивание выражению a*b недопустимо, если a и b – целые, поэтому если нет веской причины отклониться от этого поведения, оно должно быть недопустимо и для ваших типов. Когда сомневаетесь, делайте так, как ведет себя int.