Герб Саттер - Стандарты программирования на С++. 101 правило и рекомендация

[Cargill92] pp. 19-20 • [Cline99] §5.13, §7.01-8.15 • [Dewhurst03] §92 • [Liskov88] • [Meyers97] §35 • [Stroustrup00] §12.4.1, §23.4.3.1, §24.3.4 • [Sutter00] §22-24

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

Хотя обычно производные классы добавляют новые состояния (т.е. члены-данные), они моделируют подмножества (а не надмножества) своих базовых классов. При корректном наследовании производный класс моделирует частный случай более общей базовой концепции (см. рекомендацию 37).

Это имеет прямые следствия для корректного перекрытия функций. Соблюдение отношения включения влечет за собой заменимость — операции, которые применимы ко всему множеству, применимы и к любому его подмножеству. Если базовый класс гарантирует выполнение определенных пред- и постусловий некоторой операции, то и любой производный класс должен обеспечить их выполнение. Перекрытие может предъявлять меньше требований и предоставлять большую функциональность, но никогда не должно предъявлять большие требования или меньше обещать — поскольку это приведет к нарушению контракта с вызывающим кодом.

Определение в производном классе перекрытия, которое может быть неуспешным (например, генерировать исключения; см. рекомендацию 70), будет корректно только в том случае, когда в базовом классе не объявлено, что данная операция всегда успешна. Например, скажем, класс Employeeсодержит виртуальную функцию-член GetBuilding, предназначение которой — вернуть код здания, в котором работает объект Employee. Но что если мы захотим написать производный класс RemoteContractor, который перекрывает функцию GetBuilding, в результате чего она может генерировать исключения или возвращать нулевой код здания? Такое поведение корректно только в том случае, если в документации класса Employeeуказано, что функция GetBuildingможет завершаться неуспешно, и в классе RemoteContractorсообщение о неудаче выполняется документированным в классе Employeeспособом.

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

class Base {

// ...

virtual void Foo(int x = 0);

};

class Derived : public Base {

// ...

virtual void Foo(int x = 1); // лучше так не делать...

};

Derived *pD = new Derived;

pD->Foo(); // Вызов pD->Foo(1)

Base *pB = pD;

pB->Foo(); // вызов pB->Foo(0)

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

Желательно добавлять ключевое слово virtualпри перекрытии функций, несмотря на его избыточность — это сделает код более удобным для чтения и понимания.

Не забывайте о том, что перекрытие может скрывать перегруженные функции из базового класса, например:

class Base{ // ...

virtual void Foo(int);

virtual void Foo(int, int);

void Foo(int, int, int);

};

class Derived : public Base { // ...

virtual void Foo(int); // Перекрывает Base::Foo(int),

// скрывая остальные функции

};

Derived d;

d.Foo(1); // Все в порядке

d.Foo(1, 2); // Ошибка

d.Foo(1, 2, 3); // Ошибка

Если перегруженные функции из базового класса должны быть видимы, воспользуйтесь объявлением usingдля того, чтобы повторно объявить их в производном классе:

class Derived : public Base { // ...

virtual void Foo(int); // Перекрытие Base::Foo(int)

using Base::Foo; // вносит все прочие перегрузки

// Base::Foo в область видимости

};

Пример: Ostrich (Страус). Если класс Bird(Птица) определяет виртуальную функцию Flyи вы порождаете новый класс Ostrich(известный как птица, которая не летает) из класса Bird, то как вы реализуете Ostrich::Fly? Ответ стандартный — "по обстоятельствам". Если Bird::Flyгарантирует успешность (т.е. обеспечивает гарантию бессбойности; см. рекомендацию 71), поскольку способность летать есть неотъемлемой частью модели Bird, то класс Ostrichоказывается неадекватной реализацией такой модели.