Бертран Мейер - Основы объектно-ориентированного программирования

Что должна показывать плоская форма класса при встрече с инструкцией, использующей Precursor ?

Напишите класс WINDOW_WITH_BORDER_AND_MENU без обращения к Precursor . Для доступа к родительскому варианту переопределенного компонента используйте репликацию при дублируемом наследовании. Убедитесь в том, что вы используете правильные предложения selectи назначаете каждому компоненту правильный статус экспорта.

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

Следствия красоты базисных идей:

[x].Связь наследования с утверждениями и Проектированием по Контракту.

[x].Глобальная структура наследования, где все классы согласованы.

[x].Замороженные компоненты, для которых не применим принцип Открыт-Закрыт.

[x].Ограниченная универсальность: как задавать требования на родовые параметры.

[x].Попытка присваивания: как безопасно приводить к типу.

[x].Как и когда изменять свойства типа при повторных объявлениях.

[x].Закрепленные объявления, помогающие избежать лавины переобъявлений.

[x].Непростые отношения между наследованием и скрытием информации.

Вопросам наследования будут посвящены еще две лекции: обзор проблем типизации представлен в лекции 17, а подробное обсуждение методологии наследования - в лекции 6курса "Основы объектно-ориентированного проектирования".

Большинство разделов этой лекции строится по единому принципу: экзаменуются следствия идей предыдущих двух лекций, обнаруживаются проблемы, они подробно анализируются, предлагается обоснованное решение. Ключевым является шаг анализа - как только проблема становится ясной, зачастую решение ее находится сразу же.

Обладая изрядной мощью, наследование может быть и опасным. Не будь механизма утверждений, создатели классов могли бы весьма "вероломно" пользоваться повторными объявлениями и динамическим связыванием для изменения семантики операций без возможности контроля со стороны клиента. Утверждения способны на большее: они дают нам боле глубокое понимание природы наследования. Не будет преувеличением сказать, что лишь понимание принципов Проектирования по Контракту позволяет в полной мере постичь сущность концепции наследования.

Вкратце мы уже очертили основные правила, управляющие взаимосвязью наследования и утверждений: все утверждения (предусловие и постусловия подпрограмм, инварианты классов), заданные в классах-родителях, остаются в силе и для их потомков. В этом разделе мы уточним эти правила и используем полученные результаты, чтобы дать новый взгляд на наследование как на субподряды (subcontracts).

С правилом об инвариантах класса мы встречались и прежде:

Правило родительских инвариантов

Инварианты всех родителей применимы и к самому классу.

Инварианты родителей добавляются к классу. Инварианты соединяются логической операцией and then. (Если у класса нет явного инварианта, то инвариант True играет эту роль.) По индукции в классе действуют инварианты всех его предков, как прямых, так и косвенных.

Как следствие, выписывать инварианты родителей в инварианте потомка еще раз не нужно (хотя семантически такая избыточность не вредит: a and then aесть то же самое, что a ).

Полностью восстановленный инвариант класса можно найти в плоской и краткой плоской форме последнего (см. лекцию 15).

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