Блинков Ю.А., Месянжин В.В. (сост) Основы объектно-ориетнированного программирования. Саратовский Государственный университет, механико-математический факультет

Подождите немного. Документ загружается.

13.2 Наследование и скрытие информации

Последний вопрос, оставшийся пока без ответа, как наследование взаимодействует с принципом

Скрытия информации.

В отношениях между классом и его клиентами скрытие информации определяет разработчик

класса. Именно он определяет политику в отношении каждого компонента класса: экспортируя его

всем клиентам, разрешая выборочный экспорт, или делая компонент закрытым.

Кое-что о политике

Что происходит со статусом экспорта при передаче компонента потомку? Наследование и скрытие

информации - ортогональные механизмы. Наследование определяет отношение между классом и его

потомками, экспорт - между классом и его клиентами. Класс B может свободно экспортировать

или скрывать любой из компонентов f, унаследованных им от классаA. При этом доступны все

возможные комбинации:

• f экспортируется в классе A и в классе B (хотя и не обязательно одним и тем же клиентам);

• f скрыто в A и B;

• f скрыто в A, но полностью или частично экспортируется в B;

• f экспортируется в A, но скрыто в B.

Применение

Характерным примером является создание нескольких вариантов одной абстракции.

Рис. 13.2: Разные облики одной абстракции

Представим себе GENERAL_ACCOUNT - класс, содержащий все необходимые операции для ра-

боты с банковскими счетами: процедуры open, withdraw, deposit, code (для снятия денег через банко-

мат), change_code и т.д.,- но не предназначенный для использования клиентами напрямую, а потому

не экспортирующий никаких подпрограмм. Его потомки выступают как разные облики родителя: они

не содержат новых компонентов и отличаются лишь предложениями экспорта. Один экспортирует

open и deposit, второй, наряду с ними, - withdraw и code, и т. д.

Ключевые концепции

• К инварианту класса автоматически добавляются инварианты его родителей.

• В подходе Проектирования по Контракту наследование, переопределение и динамическое свя-

зывание приводят к идее субподрядов.

• Повторное объявление подпрограммы (переопределение или создание реализации) может со-

хранить или ослабить предусловие, сохранить или усилить постусловие.

• Ограниченная универсальность дает возможность использовать только родовые параметры со

специфическими свойствами.

• Попытка присваивания позволяет динамически проверить, принадлежит ли объект ожидаемому

типу. Эта операция не должна использоваться как замена динамического связывания.

• Потомок вправе переопределять тип любой сущности (атрибута, результата функции, формаль-

ного параметра подпрограммы). Повторное определение должно быть ковариантным - заменять

исходные типы соответствующими, согласуясь с требованиями потомка.

• Наследование и скрытие информации - это независимые механизмы. Потомки могут скрывать

экспортированные компоненты и экспортировать скрытые компоненты.

• Компонент, доступный самому классу, доступен и его потомкам.

Контрольные вопросы

1. При повторном объявлении компонента

постусловие ослабляет требования, предъявляемые к работе компонента

предусловие сужает число ситуаций, допустимых у клиента

постусловие ужесточает требования, предъявляемые к работе компонента

предусловие расширяет число ситуаций, допустимых у клиента

2. Инвариант класса

является конъюнкцией собственного инварианта класса и собственного инварианта родителя

если у класса нет собственного инварианта, то инвариант True играет эту роль

совпадает с собственным (непосредственным) инвариантом класса – конъюнкцией утвержде-

ний из его раздела invariant

является конъюнкцией собственных инвариантов всех предков класса

3. Если наследник повторно объявляет компонент родителя, то, чтобы не обмануть клиентов, он

должен

усилить или сохранить постусловие компонента

усилить или сохранить предусловие компонента

ослабить или сохранить предусловие компонента

ослабить или сохранить постусловие компонента

4. Контракты и субподряды. Под субподрядом понимается создание класса – наследника суще-

ствующего класса. Субподрядчик

вправе улучшить для клиентов условия контракта

не вправе изменить существующий контракт

обязан удовлетворить всем требованиям существующего контракта

может эффективнее выполнить работу, предусмотренную контрактом

5. Попытка присваивания

предполагает динамическую проверку соответствия типов левой и правой части присваивания

это специальное обобщение операции присваивания

это присваивание цели значения void в случае несоответствия типов

присваивание, заканчивающееся отказом

6. Ограничение универсальности

позволяет расширить набор операций, допустимых при работе с объектами

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

типа

дает возможность задавать в качестве фактического параметра тип с заданным набором опе-

раций

ограничивает возможности работы с объектами в сравнении с неограниченной универсально-

стью

7. При повторном объявлении

разрешается изменение типа атрибута и типа аргументов у компонентов в соответствии с

правилами согласованности типов

требуется сохранение сигнатуры компонента

разрешается изменение сигнатуры компонента

разрешается произвольное изменение типа атрибута и типа аргументов у компонентов

8. Экспорт и наследование

экспорт компонента клиенту означает, что компонент экспортируется всем потомкам этого

клиента

все компоненты класса должны быть доступны его потомкам

экспорт компонента клиенту еще не означает, что компонент экспортируется всем потомкам

этого клиента

экспорт компонентов может быть выборочным; тот или иной компонент можно экспортировать

одному или нескольким клиентам

9. Отметьте истинные высказывания

наследование и скрытие информации – это взаимозависимые механизмы

компонент, доступный классу, может быть не доступен его потомкам

утверждения дают глубокое понимание природы наследования

при повторном использовании интерфейсов скрывается информация о реализации

10. Отметьте истинные высказывания

при повторном использовании реализаций информация скрывается

попытка присваивания может заменить динамическое связывание

повторное объявление должно удовлетворять утверждениям оригинальной подпрограммы

у клиента нет возможности контроля изменения семантики операций создателями классов,

пользующимися повторными объявлениями и динамическим связыванием

11. Отметьте истинные высказывания?

лишь понимание принципов Проектирования по Контракту позволяет в полной мере постичь

сущность концепции наследования

при повторном использовании интерфейсов реализация не защищена

экспорт определяет отношения между классом и его потомками

заморозив компонент, можно гарантировать его семантическую уникальность

Набрано баллов

14 Типизация

Эффективное применение объектной технологии требует четкого описания в тексте системы типов

всех объектов, с которыми она работает на этапе выполнения. Это правило, известное как статиче-

ская типизация (static typing), делает наше ПО: более надежным, позволяя компилятору и другим

инструментальным средствам устранять несоответствия прежде, чем они смогут нанести вред; более

понятным, обеспечивая точной информацией читателей: авторов клиентских систем и тех, кто будет

сопровождать систему; более эффективным, поскольку информация о типах данных позволит ком-

пилятору сгенерировать оптимальный код. Хотя вопросами типизации данных активно занимались и

вне объектной среды, да и сама статическая типизация применяется в языках, не поддерживающих

ООП, особенно ярко эти идеи проявили себя именно при объектном подходе, во многом основанном

на понятии типа, которое, сливаясь с понятием модуля, образует базовую ОО-конструкцию - класс.

14.1 Проблема типизации

О типизации при ОО-разработке можно сказать одно: эта задача проста в своей постановке, но

решить ее подчас нелегко.

Базисная конструкция

Простота типизации в ОО-подходе есть следствие простоты объектной вычислительной модели.

Опуская детали, можно сказать, что при выполнении ОО-системы происходят события только одного

рода - вызов компонента (feature call):

x.f (arg)

означающий выполнение операции f над объектом, присоединенным к x, с передачей аргумента arg

(возможно несколько аргументов или ни одного вообще). Программисты говорят в этом случае о

“передаче объекту x сообщения f с аргументом arg”, но это - лишь отличие в терминологии, а

потому оно несущественно.

То, что все основано на этой Базисной Конструкции (Basic Construct), объясняет частично ощу-

щение красоты ОО-идей.

Из Базисной Конструкции следуют и те ненормальные ситуации, которые могут возникнуть в

процессе выполнения:

Определение: нарушение типа

Нарушение типа в период выполнения или, для краткости, просто нарушение типа (type violation)

возникает в момент вызова x.f (arg), где x присоединен к объекту OBJ, если либо:

• не существует компонента, соответствующего f и применимого к OBJ,

• такой компонент имеется, однако, аргумент arg для него недопустим.

Ключевым является слово когда. Рано или поздно вы поймете, что имеет место нарушение типа.

Например, попытка выполнить компонент “Пуск торпеды” для объекта “Служащий” не будет рабо-

тать и при выполнении произойдет отказ. Однако возможно вы предпочитаете находить ошибки как

можно раньше, а не позже.

Статическая и динамическая типизация

Хотя возможны и промежуточные варианты, здесь представлены два главных подхода:

• Динамическая типизация: ждать момента выполнения каждого вызова и тогда принимать ре-

шение.

• Статическая типизация: с учетом набора правил определить по исходному тексту, возможны ли

нарушения типов при выполнении. Система выполняется, если правила гарантируют отсутствие

ошибок.

Эти термины легко объяснимы: при динамической типизации проверка типов происходит во время

работы системы (динамически), а при статической типизации проверка выполняется над текстом

статически (до выполнения).

Термины типизированный и нетипизированный (typed/untyped) нередко используют вместо стати-

чески типизированный и динамически типизированный (statically/dynamically typed). Во избежание

любых недоразумений мы будем придерживаться полных именований.

Статическая типизация предполагает автоматическую проверку, возлагаемую, как правило, на

компилятор. В итоге имеем простое определение:

Определение: статически типизированный язык

ОО-язык статически типизирован, если он поставляется с набором согласованных правил, прове-

ряемых компилятором, соблюдение которых гарантирует, что выполнение системы не приведет к

нарушению типов.

В литературе встречается термин “сильная типизация” (strong). Он соответствует ультиматив-

ной природе определения, требующей полного отсутствия нарушения типов. Возможны и слабые

(weak) формы статической типизации, при которых правила устраняют определенные нарушения, не