Бадд Т. Объектно-ориентированное программирование
Подождите немного. Документ загружается.
описываются. Программистам рекомендуется применять их как более безопасные
средства вместо прежнего механизма приведения типов.
10.2.5. Связывание в языке Java
Хотя внешне язык Java похож на С++, его способы связывания сообщений и поиска
подходящих методов существенно проще, чем в С++. В Java все переменные знают
свой динамический тип данных. Предполагается, что подклассы являются
подтипами, и поэтому значение может быть присвоено типу родительского класса
без явного преобразования. Обратное присваивание (обращение полиморфизма)
допускается с явным приведением типа. Для того чтобы определить допустимость
присваивания, во время выполнения программы производится проверка и, если
присваивание недопустимо, индуцируется исключительная ситуация.
Ball aBallValue;
// ... пропущенный код
// выполнить присваивание через обращение полиморфизма
BlackBall bball = (BlackBall) aBallValue;
Также можно проверять динамический тип значения, используя оператор
instanceOf.
if (aBallValue instanceOf BlackBall)
...
else
...
Сообщения всегда связываются с методами на основе динамического типа данных
получателя. В отличие от C++ ключевые слова virtual отсутствуют. Интересная
особенность языка Java состоит в том, что поля данных также могут
переопределяться, но в этом случае доступ к переменной основывается на
статическом типе данных, а не на динамическом. Оба случая переопределения
иллюстрируются следующим примером:
class A
{
String name = "class A";
public void print()
{
println("class A");
}
}
class B extends A
{
String name = "class B";
public void print()
{
println("class B");
}
}
class test
{
public void test()
{
Class B b = new B();
Class A a = b;
println(a); // печатает "класс А"
println(b); // печатает "класс В"
PDF created with pdfFactory Pro trial version www.pdffactory.com
a.print(); // печатает "класс В", а не "класс А"
b.print(); // печатает "класс В"
}
}
Хотя язык Java смешивает понятия подкласса и подтипа, предполагая, что все
подклассы являются подтипами, но из всех рассматриваемых нами строго
типизированных языков Java наиболее четко разделяет эти концепции, предлагая
понятие интерфейса.
Интерфейсы обеспечивают иерархическую организацию, подобную классам, но не
зависят от последних. Как отмечалось в главе 7, интерфейсы определяют только
протокол выполнения операций, но не их реализацию. Используя ключевое слово
extends, можно строить новые интерфейсы поверх существующих, как это делается
для классов. Таким образом создается иерархия подтипов, полностью независимая
от иерархии подклассов.
Интерфейсы могут использоваться для определения переменных, которые будут
принимать значения любых типов, заявляющих, что они реализуют интерфейс. Тем
самым статический тип — это тип интерфейса, тогда как динамический тип — это
тип класса. Связывание основывается на динамическом типе.
Например, при проектировании на языке Java системы итератора для структур
данных (см. главу 16, где обсуждаются итераторы) можно представить себе
иерархию итераторов: однонаправленные, двунаправленные, с произвольным
доступом. Они определены следующими протоколами:
interface forwardIterator
{
void advance();
int currentValue();
}
interface bidirectionalIterator extends forwardIterator
{
void moveBack();
}
interface randomAccessIterator extends
bidirectionalIterator
{
int at(int);
}
Структуры данных могут затем определить нужный итератор. Это задается
реализацией.
class listIterator implements forwardIterator
{
// ...
}
10.3. Как связывать: статически или динамически?
Споры по поводу относительных достоинств статических и динамических типов
данных, а также статического и динамического связывания неизменно сводятся к
противопоставлению эффективности и гибкости. Формулируя вкратце, статические
PDF created with pdfFactory Pro trial version www.pdffactory.com
типы данных и статическое связывание более эффективны, а динамические типы
данных и динамическое связывание более гибки.
Как мы видели, динамические типы данных подразумевают, что каждый объект
должен отслеживать свой собственный тип данных. Если мы посмотрим на
объекты с точки зрения «непреклонного индивидуалиста» (каждый объект должен
сам заботиться о себе и не зависеть от других), то динамические типы данных
кажутся более объектно-ориентированной методикой. Их применение сильно
упрощает, например, разработку структур данных общего назначения. Но не все
так просто — во время выполнения происходит постоянный поиск подходящего
кода. Хотя имеются способы уменьшения этих затрат, они не могут быть
устранены полностью. В основном именно потому, что такие накладные расходы
могут быть весьма значительными, большинство языков программирования
использует статические типы данных.
Статические типы данных упрощают реализацию языка, даже если (как в Java,
Object Pascal и иногда в C++) используется динамическое связывание метода с
сообщением. Когда компилятору известны статические типы данных, выделение
памяти под переменные происходит более эффективно, а для простых операций
(например, сложение чисел) генерируется почти совершенный код. Но имеются
затраты, связанные и со статическими типами данных. К примеру, часто объекты
могут терять знание о себе (хотя это не обязательно, как мы видели в случае языка
Object Pascal). Как мы отмечали при обсуждении проблемы контейнеров данных,
этот факт затрудняет написание абстракций структур данных общего назначения.
Если статические типы данных упрощают реализацию языка программирования, то
статическое связывание делает его почти элементарным. Если соответствие между
методом и сообщением может быть обнаружено компилятором, то пересылка
сообщений (независимо от используемого синтаксиса) представляется просто как
вызов процедуры: во время выполнения уже не требуется поиск подходящего
метода. Это, по-видимому, максимально эффективно (хотя механизм inline-
функций в C++ может устранить даже и код вызова процедуры).
Напротив, динамическое связывание всегда требует некоего run-time-механизма
(хотя бы и примитивного) для сопоставления метода и сообщения. В языках
программирования, которые используют динамические типы данных (и, как
следствие, динамическое связывание), вообще говоря, нельзя определить заранее,
будет ли пересылаемое сообщение восприниматься получателем. Когда сообщение
не распознается, то не остается другой альтернативы, кроме как сгенерировать
сообщение об ошибке этапа выполнения. Защитники статических языков
программирования настаивают, что большинство таких ошибок может быть
отловлено на этапе компиляции для языка со статическим связыванием методов.
Эта точка зрения оспаривается (как и следовало ожидать) сторонниками
динамического программирования.
Тем самым нам приходится решать, что более важно: эффективность или гибкость,
правильность или легкость использования. Брэд Кокс [Cox 1986] настаивает, что
решение зависит как от уровня абстракции программы, так и от того, являемся ли
мы производителями или потребителями программной системы. Кокс утверждает,
что объектно-ориентированное программирование будет основным (хотя и не
единственным) средством в «революции в области программной индустрии».
Точно так же как в девятнадцатом веке индустриальная революция стала возможна
PDF created with pdfFactory Pro trial version www.pdffactory.com
только после разработки взаимозаменяемых деталей, так и целью программной
революции является конструирование многократно используемых и надежных
абстрактных компонент высокого уровня для программного обеспечения, из
которых собираются реальные приложения.
Эффективность — главное, о чем следует думать на низком уровне (Кокс называет
этот уровень «абстракцией уровня транзисторов» («gate-level abstractions») по
аналогии с электроникой). По мере повышения уровня абстракции (до
интегральных микросхем и готовых плат) гибкость становится более
существенной.
Эффективность программы является первостепенной заботой разработчика. Для
потребителя, заинтересованного в комбинировании программных систем, гибкость
может быть более важной.
Итак, нет единственно правильного ответа на вопрос, какая из техник связывания
является более подходящей. Все зависит от конкретной ситуации.
Упражнения
• Язык Object Pascal использует и статические типы данных, и динамическое
связывание. Объясните, почему обратная ситуация (динамические типы
данных и статическое связывание сообщений с методами) невозможна.
• Проиллюстрируйте, почему в объектно-ориентированных языках
программирования со статическими типами данных (например, C+ или
Object Pascal) компилятор проверяет, чтобы значение переменной
родительского класса не присваивалось переменной, описанной как
экземпляр подкласса.
• Подумайте о том, стоит ли проверка ошибок, которая становится возможной
при статических типах данных, проигрыша в гибкости. Насколько важны
контейнерные классы?
• Где не срабатывает аналогия Брэда Кокса между аппаратным и
программным обеспечением? Что препятствует разработке переносимых
надежных программных компонент?
Глава 11: Замещение и уточнение
До сих пор в нашей интуитивной модели наследования данные и методы дочерних
классов оказывались шире, чем в родительском классе. То есть подкласс просто добавлял
новые данные или методы к тем, что были унаследованы от надкласса. Однако ясно, что
это не всегда имеет место. Помните утконосов Фила и Филлис, описанных в главе 1? В
соответствии с нашими рассуждениями млекопитающие — это живородящие. Тем не
менее Филлис, стойко требующая отнести ее к законным членам семейства
млекопитающих, дает жизнь детенышам, откладывая яйца.
В этой ситуации подкласс утконосов Platypus не просто добавляет что-то к информации о
родительском классе млекопитающих Mammal. На самом деле дочерний класс изменяет
некоторые свойства родительского класса. Чтобы понять, как подкласс модифицирует
смысл метода родительского класса, мы должны исследовать понятие наследования более
подробно.
11.1. Добавление, замещение и уточнение
PDF created with pdfFactory Pro trial version www.pdffactory.com
Мы предполагали до сих пор, что данные и методы, которые добавляют подклассы,
отличаются от унаследованных от родительского класса. Другими словами, методы и
значения данных, доопределенные дочерним классом, отличаются от значений и методов
родительских (и прародительских) классов. Мы говорим о такой ситуации, как о
добавлении к протоколу родительского класса.
Все меняется, когда дочерний класс определяет некоторый метод под тем же самым
именем, что и в родительском классе. В результате метод дочернего класса
переопределяет метод родительского класса. Например, мои специфические знания о
классе утконосов изменяют мои взгляды на класс млекопитающих.
Как описано в главе 1, если сообщение посылается некоторому объекту, то поиск
подходящего метода всегда начинается с проверки методов, связанных с классом этого
объекта. Если ни один метод не найден, проверяются методы, связанные с ближайшим
родительским классом. Если опять-таки ни один метод не найден, проверяется
ближайший родительский класс родительского класса и т. д. В конце концов либо больше
уже не остается классов (и тогда выдается сообщение об ошибке), либо находится
подходящий метод.
Говорят, что метод в классе, имеющий то же имя, что и в надклассе, переопределяет
(override) метод надкласса. Во время поиска метода, который вызывается в качестве
реакции на сообщение, метод дочернего класса, естественно, будет найден раньше, чем
одноименный метод в родительском классе. (По большей части переопределение связано
только с методами. Java — единственный из обсуждаемых нами языков
программирования (и не только среди них), который допускает ограниченную форму
переопределения полей данных.)
11.1.1. Американская и скандинавская семантики
Метод дочернего класса может переопределять наследуемый метод одним из двух
способов. В случае замещения метод родительского класса замещается целиком во время
работы программы. То есть код родительского класса никогда не исполняется при
обработке экземпляров дочернего класса. Уточняющий метод включает в себя как часть
своих действий вызов метода родительского класса. Таким образом, родительское
поведение сохраняется и присоединяется.
Первый тип переопределения часто называют американской семантикой, поскольку он
обычно ассоциируется с языками программирования американского происхождения
(Smalltatk или C++). Второй известен как скандинавская семантика, так как он чаще всего
ассоциируется с языком Simula [Dahl 1966, Birtwistle 1979, Kirkerud 1989], первым
объектно-ориентированным языком программирования, и с более поздним языком Beta
[Madsen 1993]. Оба языка имеют скандинавское происхождение.
В главе 7 мы описали механизм добавления нового метода в дочерний класс. Остальная
часть данной главы посвящена механизму замещения и уточнения в каждом из
рассматриваемых нами языков. Мы поговорим также о некоторых достоинствах и
недостатках этих двух подходов.
11.2. Замещение методов
PDF created with pdfFactory Pro trial version www.pdffactory.com
В языке Smalltalk целые числа и числа с плавающей точкой являются объектами —
экземплярами классов Integer и Float соответственно. В свою очередь оба эти класса —
подклассы более общего класса Number. Теперь предположим, что у нас есть переменная
aNumber, которая содержит в текущий момент значение, относящееся к классу целых
чисел, и мы посылаем этой переменной сообщение sqrt, вызывающее вычисление
квадратного корня. Метода, соответствующего этому имени, в классе Integer нет, поэтому
исследуется класс Number и находится следующий метод:
sqrt
" преобразовать к числам с плавающей точкой "
" затем вычислить квадратный корень "
self asFloat sqrt
Этот метод посылает сообщение asFloat переменной self, которая получила сообщение
sqrt. Сообщение asFloat возвращает число с плавающей точкой той же величины, что и
исходное целое. Затем этому значению посылается сообщение sqrt. Поиск метода
начинается с класса Float. Обнаруживается, что класс Float содержит метод с тем же
именем sqrt, который для чисел с плавающей точкой переопределяет собой метод в классе
Number. Метод класса Float (который здесь не приведен) вычисляет и возвращает
квадратный корень.
Переопределение и полное замещение метода sqrt означает, что многие типы чисел могут
обладать единственной процедурой по умолчанию, расположенной в классе всех чисел
Number. Такое совместное использование позволяет избежать необходимости повторять
этот код для каждого подкласса класса Number (который содержит не только целые числа
и числа с плавающей точкой, но и целые числа с неограниченной разрядностью, а также
рациональные числа). Классы типа Float, которые требуют отличного от установленного
по умолчанию поведения, легко могут переопределять метод и подставлять
альтернативный код.
11.2.1. Замещение методов и принцип подстановки
Основная трудность при использовании замещения методов в качестве фундаментальной
модели наследования — предположение, что подклассы являются подтипами. Вспомните,
что основой принципа подстановки является то, что представители подкласса ведут себя
во всех существенных отношениях подобно представителям родительского класса. Но
если подклассы могут переопределять методы, то где гарантии того, что поведение
дочернего класса будет иметь хоть какое-то отношение к родительскому классу?
В только что упомянутом примере методы в обоих классах — Float и Number — были
связаны только их концептуальными отношениями к абстрактному понятию «квадратный
корень». Может возникнуть большой беспорядок, если подкласс поменяет поведение
унаследованного метода слишком радикально — например, изменяя sqrt так, чтобы он
вычислял логарифм.
В языках программирования можно встретить несколько возможных путей решения
конфликта между замещением методов и принципом подстановки:
1. Просто игнорировать эту проблему и предоставить программисту заботиться о том,
чтобы подклассы делали правильные вещи во всех важных ситуациях. Этот подход
принят на вооружение во всех рассматриваемых нами языках программирования:
Object Pascal, C++, Objective-C, Java и Smalltalk.
PDF created with pdfFactory Pro trial version www.pdffactory.com
2. В языке Eiffel [Meyer 1988a, Rist 1995], еще одном хорошо известном объектно-
ориентированном языке, программист может присоединить к методу утверждения.
Они являются логическими выражениями, которые проверяют состояние объекта
во время исполнения, обеспечивая тем самым выполнение определенных условий.
Утверждения автоматически наследуются подклассами в прежней форме, даже
когда текущие методы переопределяются методами подкласса. Таким образом,
утверждения могут использоваться для того, чтобы удостовериться, что дочерний
класс ведет себя допустимым образом.
3. Разделить понятия подкласса и подтипа, как это частично сделано в Java.
Подклассы затем могут использовать семантику замещения в качестве техники
реализации, при этом не обязательно подразумевая, что результирующий класс
будет подтипом первоначального класса.
4. Совершенно отбросить семантику замещения, а использовать уточнение. Эта
возможность рассматривается в следующем разделе.
11.2.2. Уведомление о замещении
Языки программирования используют различные подходы к указанию на то, что
некоторый метод переопределяется (неважно как: с замещением или уточнением).
Smalltalk, Java и Objective-C вообще не требуют указания на переопределение. В C++
базовый (родительский) класс должен иметь специальные указания о возможности
переопределения. В языке Object Pascal версии Apple это указание происходит не в
родительском, а в дочернем классе. В языке Delphi Pascal ключевое слово должно быть
помещено в оба класса.
Расположение какого-либо указания в родительском классе обычно облегчает
реализацию, поскольку если нет возможности переопределить метод, то посылка
сообщения реализуется через более эффективный вызов процедуры (то есть динамический
поиск во время выполнения не нужен). С другой стороны, снятие необходимости
уведомления делает язык более гибким, так как позволяет из любого класса порождать
подклассы, даже если автор родительского класса не предусматривал такой возможности.
Например, один программист создает класс (скажем, List) для конкретного приложения.
Позднее другой программист захочет построить специализированную форму этого класса
(например, OrderedList), переопределяя многие его методы. В таких языках, как C++, это
потребует текстовых изменений в исходном классе, чтобы объявить методы как
виртуальные (virtual). Напротив, в Java или Objective-C не потребуется никаких изменений
в описании родительского класса.
11.3. Замещение в разных языках
Ниже кратко характеризуется замещение в различных языках программирования.
11.3.1. Замещение в C++
Переопределение методов в языке C++ усложняется взаимным перекрытием
переопределения, перегрузки, виртуальных (или полиморфных) функций и
конструкторов. Перегрузка и виртуальные функции рассмотрены подробнее в следующих
главах. В этом же разделе мы ограничимся простым замещением (листинг 11.1).
Листинг 11.1. Описания класса и подкласса в C++
PDF created with pdfFactory Pro trial version www.pdffactory.com
class CardPile
{
public:
CardPile (int, int);
card & top();
void pop();
bool empty();
virtual bool includes(int, int);
virtual void select(int, int);
virtual void addCard(card &);
virtual void display(window &);
virtual void canTake(card &);
protected:
Card * firstCard;
int x;
int y;
};
class SuitPile : public CardPile
{
public:
SuitPile(int, int);
virtual bool canTake(card &);
};
Простое замещение встречается в том случае, когда 1) аргументы метода дочернего класса
идентичны по типу и числу аргументов методу родительского класса, 2) для описания
метода в родительском классе используется модификатор virtual
1
. Пример: класс
CardPile, используемый в пасьянсе из главы 8. Если мы должны перевести пасьянс на C++,
то объявления могут выглядеть примерно так, как в листинге 11.1, где представлено
описание класса CardPile и его подкласса (в данном случае SuitPile).
Метод canTake описан таким образом, что он переопределяет метод родительского класса.
Последний «говорит только нет» — он всегда возвращает значение «ложь» в ответ на
запрос, можно ли положить в стопку новую карту:
bool CardPile::canTake (card & c) {
// всегда «нет»
return false;
}
Напротив, этот метод в классе SuitPile дает значение «истина», если колода пуста и карта
является тузом или если карта подходит по масти верхней карте колоды и на единицу
больше ее по рангу:
bool SuitPile::canTake (card & c)
{ // можно добавить к стопке туза
if (empty ())
return c.rank() == 0;
card & topcard = top()
// иначе должно быть совпадение по масти
// и карта должна быть следующей по старшинству
if ((c.suit() == topcard.suit()) &&
1
За одним исключением: когда тип возвращаемого значения для функции, описанной в дочернем классе, не
совпадает с типом возвращаемого значения метода родительского класса. См. раздел 12.3.1 следующей
главы.
(c.rank() == 1 + topcard.rank()))
return true;
return false;
PDF created with pdfFactory Pro trial version www.pdffactory.com
}
Для этой методики совершенно необходимо, чтобы метод дочернего класса полностью
перекрывал метод родителя.
Для компилятора языка C++ есть тонкий смысловой нюанс в том, объявлен ли метод
canTake виртуальным и в классе CardPile тоже. Оба варианта имеют право на
существование. Чтобы метод работал в соответствии с тем, что мы называем объектно-
ориентированным стилем, он должен быть объявлен как виртуальный. Модификатор
virtual необязателен при описании в дочернем классе. Как только метод объявляется
виртуальным, он остается виртуальным и во всех подклассах. Однако для целей
документирования этот модификатор обычно повторяется во всех производных классах.
Если модификатор virtual не задан, метод по-прежнему будет замещать одноименный
метод родительского класса. Однако процесс связывания метода и сообщения будет
происходить по-другому. Невиртуальные методы являются статическими в смысле,
описанном в главе 10. То есть связывание вызова невиртуального метода будет
выполняться во время компиляции, исходя из объявленного (статического) типа
получателя, а не во время выполнения программы, исходя из динамического типа
получателя. Если ключевое слово virtual удалено из описания метода canTake, то
переменные, объявленные как SuitPile, будут выполнять метод из класса SuitPile, а
переменные, объявленные как CardPile, будут выполнять метод по умолчанию независимо
от действительного значения переменной.
Еще один усложняющий фактор при переопределении функций в языке C++ — это
взаимодействие между перегрузкой и переопределением. Мы будем обсуждать это в
главе 17. Сложная семантика замещения методов в языке C++ находится в согласии с его
философией, которая состоит в том, что свойства языка должны приводить к
дополнительным накладным расходам во время выполнения программы только в том
случае, когда эти свойства используются. Если виртуальные функции не применяются, то
наследование не навязывает
абсолютно никаких издержек времени выполнения. Это не так для других
рассматриваемых нами языков программирования. Однако тот факт, что синтаксисом
языка дозволены как виртуальные, так и невиртуальные формы записи, причем это
приводит к различиям в интерпретации, часто является источником трудноуловимых
ошибок в программах на языке C++.
Конструкторы в C++ всегда используют семантику уточнения, а не замещения. Мы
обсудим это после того, как введем понятие уточнения методов.
11.3.2. Замещение методов в Object Pascal
В языке Object Pascal версии фирмы Apple метод может замещать метод надкласса, только
если:
• имя метода пишется точно так же, как в родительском классе;
• порядок, типы, имена параметров и тип результата функций точно совпадают;
• описание метода в дочернем классе следует за ключевым словом override.
Листинг 11.2 иллюстрирует замещение метода. Здесь класс Employee — общее описание
служащих фирмы, а классы SalaryEmployee и HourlyEmployee — два его подкласса.
PDF created with pdfFactory Pro trial version www.pdffactory.com
Функция computePay в классе Employee вычисляет зарплату за данный период. Этот метод
переопределяется для подклассов, поскольку вычисления, используемые для двух типов
служащих, различны.
Рассмотрим переменную emp, объявленную как экземпляр класса Employee. Как мы уже
отмечали, она может иметь значение либо класса SalaryEmployee, либо класса
HourlyEmployee (или любого другого типа служащих). Независимо от ее значения
обращение к процедуре computePay приведет к вызову нужного метода для
соответствующего типа служащих.
Синтаксис, используемый языком Delphi Pascal фирмы Borland, гораздо ближе к C++. В
языке фирмы Borland метод, переопределяемый в подклассах, должен следовать за
ключевым словом virtual в родительском классе, как это показано в листинге 11.3.
Листинг 11.2. Замещение метода в языке Object Pascal фирмы Apple
type
Employee = objet
name : alpha;
function computePay : integer;
function hourlyWorker : boolean;
procedure create;
end;
SalaryEmployee = object (Employee)
salary : integer;
function computePay : integer; override;
function hourlyWorker : boolean; override;
procedure create; override;
end;
HourlyEmployee = object (Employee)
wage : integer;
hourworked : integer;
function computePay : integer; override;
function hourlyWorker : boolean; override;
procedure create; override;
end;
function Employee.computePay : integer;
begin
return 0; (* будет переопределяться подклассами *)
end;
function HourlyEmployee.computePay : integer;
begin
return hoursworked * wage;
(* зарплата равна числу часов, умноженному на ставку *)
end;
function SalaryEmployee.computePay : integer;
begin
return salary div 12;
(* делим установленную зарплату в год на число месяцев *)
end;
Листинг 11.3. Уведомление о замещении в Delphi Pascal
type
Employee = class (TObject)
name : string;
function computePay : integer; virtual;
function hourlyWorker : boolean; virtual;
constructor create; virtual;
end;
PDF created with pdfFactory Pro trial version www.pdffactory.com