Несмотря на двадцатилетнюю историю объектно-ориентированного проектирования, цель и практика открытого наследования часто понимается неверно, и многие применения наследования оказываются некорректными.
Открытое наследование в соответствии с принципом подстановки Лисков (Liskov Substitution Principle [Liskov88]) всегда должно моделировать отношение 'является' ('работает как'): все контракты базового класса должны быть выполнены, для чего все перекрытия виртуальных функций-членов не должны требовать большего или обещать меньше, чем их базовые версии. Код, использующий указатель или ссылку на Base
, должен корректно вести себя в случае, когда указатель или ссылка указывают на объект Derived
.
Неверное использование наследования нарушает корректность. Обычно некорректно реализованное наследование не подчиняется явным или неявным контрактам, установленным базовым классом. Такие контракты могут оказаться очень специфичными и хитроумными, и программист должен быть особенно осторожен, когда их нельзя выразить непосредственно в коде (некоторые шаблоны проектирования помогают указать в коде его предназначение — см. рекомендацию 39).
Наиболее часто в этой связи упоминается следующий пример. Рассмотрим два класса — Square
(квадрат) и Rectangle
(прямоугольник), каждый из которых имеет виртуальные функции для установки их высоты и ширины. Тогда Square
не может быть корректно унаследован от Rectangle
, поскольку код, использующий видоизменяемый Rectangle
, будет полагать, что функция SetWidth
не изменяет его высоту (независимо от того, документирован ли данный контракт классом Rectangle
явно или нет), в то время как функция Square::SetWidth
не может одновременно выполнить этот контракт и свой инвариант 'квадратности'. Но и класс Rectangle
не может корректно наследовать классу Square
, если его клиенты Square полагают, например, что для вычисления его площади надо возвести в квадрат ширину, либо используют какое-то иное свойство, которое выполняется для квадрата и не выполняется для прямоугольника
Описание 'является' для открытого наследования оказывается неверно понятым при использовании аналогий из реального мира: квадрат 'является' прямоугольником в математическом смысле, но с точки зрения поведения Square
не является Rectanglе
. Вот почему вместо 'является' мы предпочитаем говорить 'работает как' (или, если вам это больше нравится, 'используется как') для того, чтобы такое описание воспринималось максимально правильно.
Открытое наследование действительно связано с повторным использованием, но опять же не так, как привыкло думать множество программистов. Как уже указывалось, цель открытого наследования — в реализации заменимости (см. [Liskov88]). Цель отрытого наследования не в том, чтобы производный класс мог повторно использовать код базового класса для того, чтобы с его помощью реализовать свою функциональность. Такое отношение 'реализован посредством' вполне корректно, но должно быть смоделировано при помощи композиции или, только в отдельных случаях, при помощи закрытого или защищенного наследования (см. рекомендацию 34).
Вот еще одно соображение по поводу рассматриваемой темы. При корректности и целесообразности динамического полиморфизма композиция 'эгоистична' в отличие от 'щедрого' наследования. Поясним эту мысль.
Новый производный класс представляет собой частный случай существующей более общей абстракции. Существующий (динамический) полиморфный код, который использует Base&
или Base*
путем вызова виртуальных функций Base
, должен быть способен прозрачно использовать объекты класса MyNewDerivedType
, производного от Base
. Новый производный тип добавляет новую функциональность к существующему коду, который при этом не должен изменяться. Однако несмотря на неизменность имеющегося кода, при использовании им новых производных объектов его функциональность возрастает.
Новые требования, естественно, должны удовлетворяться новым кодом, но они не должны требовать внесения изменений в существующий код (см. рекомендацию 36).
До объектно-ориентированного программирования было легко решить вопрос вызова старого кода новым. Открытое наследование упростило прозрачный и безопасный вызов нового кода старым (так что применяйте шаблоны, предоставляющие возможности статического полиморфизма, который хорошо совместим с полиморфизмом динамическим — см. рекомендацию 64).
Классы стратегий добавляют новое поведение путем открытого наследования, но это не является неверным употреблением открытого наследования для моделирования отношения 'реализован посредством'.
38. Практикуйте безопасное перекрытие
Ответственно подходите в перекрытию функций. Когда вы перекрываете виртуальную функцию, сохраняйте заменимость; в частности, обратите внимание на пред- и постусловия в базовом классе. Не изменяйте аргументы по умолчанию виртуальных функций. Предпочтительно явно указывать перекрываемые функции как виртуальные. Не забывайте о сокрытии перегруженных функций в базовом классе.
Хотя обычно производные классы добавляют новые состояния (т.е. члены-данные), они моделируют
Это имеет прямые следствия для корректного перекрытия функций. Соблюдение отношения включения влечет за собой заменимость — операции, которые применимы ко всему множеству, применимы и к любому его подмножеству. Если базовый класс гарантирует выполнение определенных пред- и постусловий некоторой операции, то и любой производный класс должен обеспечить их выполнение. Перекрытие может предъявлять меньше требований и предоставлять большую функциональность, но никогда не должно предъявлять большие требования или меньше обещать — поскольку это приведет к нарушению контракта с вызывающим кодом.
Определение в производном классе перекрытия, которое может быть неуспешным (например, генерировать исключения; см. рекомендацию 70), будет корректно только в том случае, когда в базовом классе не объявлено, что данная операция всегда успешна. Например, скажем, класс Employee
содержит виртуальную функцию-член GetBuilding
, предназначение которой — вернуть код здания, в котором работает объект Employee
. Но что если мы захотим написать производный класс RemoteContractor
, который перекрывает функцию GetBuilding
, в результате чего она может генерировать исключения или возвращать нулевой код здания? Такое поведение корректно только в том случае, если в документации класса Employee
указано, что функция GetBuilding
может завершаться неуспешно, и в классе RemoteContractor
сообщение о неудаче выполняется документированным в классе Employee
способом.
Никогда не изменяйте аргумент по умолчанию при перекрытии. Он не является частью сигнатуры функции, и клиентский код будет невольно передавать различные аргументы в функцию, в зависимости от того, какой узел иерархии обращается к ней. Рассмотрим следующий пример: