Чтение онлайн

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

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

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

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

Наследование иногда рассматривается как расширение, а иногда как специализация. Хотя эти два толкования как будто противоречат друг другу, оба они истинны - но с разных точек зрения.

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

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

>Здесь мы говорим о реализуемых компонентах, а не о предлагаемых (клиентам) службах, потому что при соединении скрытия информации с наследованием, как мы увидим, B может скрыть от клиентов некоторые из компонентов, в то время как A их экспортировал своим клиентам.

Таким образом, наследование является специализацией с точки зрения типов и расширением с точки зрения модулей. Это и есть парадокс расширения-специализации: чем больше применяемых компонентов, тем меньше объектов, к которым они применяются.

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

Отложенные классы являются одним из важнейших связанных с наследованием механизмов, предназначенных для решения описанных в начале книги проблем конструирования ПО.

Насыщенные утверждениями отложенные классы хорошо подходят для представления АТД. Прекрасный пример - отложенный класс для стеков. Мы уже описывали процедуру put, сейчас приведем возможную версию полного описания этого класса.