Класс RandomShapeGenerator — своего рода «фабрика», при каждом вызове метода next() производящая ссылку на случайно выбираемый объект Shape. Заметьте, что восходящее преобразование выполняется в командах return, каждая из которых получает ссылку на объект Circle, Square или Triangle, а выдает ее за пределы next() в виде возвращаемого типа Shape. Таким образом, при вызове этого метода вы не сможете определить конкретный тип объекта, поскольку всегда получаете просто Shape.
Метод main() содержит массив ссылок на Shape, который заполняется последовательными вызовами RandomShapeGenerator.next(). К этому моменту вам известно, что имеются объекты Shape, но вы не знаете об этих объектах ничего конкретного (так же, как и компилятор). Но если перебрать содержимое массива и вызвать draw() для каждого его элемента, то, как по волшебству, произойдет верное, свойственное для определенного типа действие — в этом нетрудно убедиться, взглянув на результат работы программы.
Случайный выбор фигур в нашем примере всего лишь помогает понять, что компилятор во время компиляции кода не располагает информацией о том, какую реализацию следует вызывать. Все вызовы метода draw() проводятся с применением позднего связывания.
Теперь вернемся к программе Music.java. Благодаря полиморфизму вы можете добавить в нее сколько угодно новых типов, не изменяя метод tune(). В хорошо спланированной ООП-программе большая часть ваших методов (или даже все методы) следуют модели метода tune(), оперируя только с интерфейсом базового класса. Такая программа является расширяемой, поскольку в нее можно добавить дополнительную функциональность, определяя новые типы данных от общего базового класса. Методы, работающие на уровне интерфейса базового класса, совсем не нужно изменять, чтобы приспособить их к новым классам.
Давайте возьмем пример с объектами Instrument и включим дополнительные методы в базовый класс, а также определим несколько новых классов. Рассмотрим диаграмму (см. рисунок на обороте).
Все новые классы правильно работают со старым, неизмененным методом tune(). Даже если метод tune() находится в другом файле, а к классу Instrument присоединяются новые методы, он все равно будет работать верно без повторной компиляции. Ниже приведена реализация рассмотренной диаграммы:
продолжение &
//. polymorph"!sm/music3/Music3.java // Расширяемая программа package polymorphism music3; import polymorphism.music Note; import static net.mindview.util.Print *;
class Instrument {
void play(Note л) { print("Instrument playO " + n). }
String what О { return "Instrument". }
void adjustO { printC'Adjusting Instrument"). }
}
class Wind extends Instrument {
void play(Note n) { print ("Wind playO " + n), }
String whatO { return "Wind"; }
void adjustO { printC'Adjusting Wind"). }
}
class Percussion extends Instrument {
void play(Note n) { printC'Percussion.playO " + n). }
String whatO { return "Percussion"; }
void adjustO { printC'Adjusting Percussion"), }
}
class Stringed extends Instrument {
void play(Note n) { printC'Stringed playO " + n), }
String whatO { return "Stringed". }
void adjustO { printC'Adjusting Stringed"); }
}
class Brass extends Wind {
void play(Note n) { print("Brass.play() " + n); } void adjustO { printC'Adjusting Brass"); }
}
class Woodwind extends Wind {
void play(Note n) { print ("Woodwind playO " + n); } String whatO { return "Woodwind"; }
public class Music3 {
// Работа метода не зависит от фактического типа объекта, // поэтому типы, добавленные в систему, будут работать правильно public static void tune(Instrument i) { // ...
i.play(Note.MIDDLE_C),
}
public static void tuneAll(Instrument!!] e) { for(Instrument i : e) tune(i);
}
public static void main(String[] args) {
// Восходящее преобразование при добавлении в массив Instrument!!] orchestra = { new WindO. new PercussionO. new StringedO, new BrassO, new WoodwindО
}:
tuneAll(orchestra),
}
} /* Output. Wind.pi ayО MIDDLE_C Percussion.playO MIDDLE_C Stringed.pi ayО MIDDLE_C Brass.playO MIDDLE_C Woodwind pi ayО MIDDLE_C *///:-
Новый метод what() возвращает строку (String) с информацией о классе, а метод adjust() предназначен для настройки инструментов.
В методе main() сохранение любого объекта в массиве orchestra автоматически приводит к выполнению восходящего преобразования к типу Instrument.
Вы можете видеть, что метод tune() изолирован от окружающих изменений кода, но при этом все равно работает правильно. Для достижения такой функциональности и используется полиморфизм. Изменения в коде не затрагивают те части программы, которые не зависят от них. Другими словами, полиморфизм помогает отделить «изменяемое от неизменного».
Проблема: «переопределение» закрытых методов
Перед вами одна из ошибок, совершаемых по наивности:
//: polymorph!sm/PrivateOverride.java
// Попытка переопределения приватного метода
package polymorphism;
import static net.mindview.util.Print.*;
public class PrivateOverride {
private void f() { printCprivate f(D; } public static void main(String[] args) {
Pri vateOverride po = new DerivedO; po.fO:
}
class Derived extends PrivateOverride {
public void f() { print("public f()"). } } /* Output
private f() *///-
Вполне естественно было бы ожидать, что программа выведет сообщение public f(), но закрытый (private) метод автоматически является неизменным (final), а заодно и скрытым от производного класса. Так что метод f() класса Derived в нашем случае является полностью новым — он даже не был перегружен, так как метод f() базового класса классу Derived недоступен.
Из этого можно сделать вывод, что переопределяются только методы, не являющиеся закрытыми. Будьте внимательны: компилятор в подобных ситуациях не выдает сообщений об ошибке, но и не делает того, что вы от него ожидаете. Иными словами, методам производного класса следует присваивать имена, отличные от имен закрытых методов базового класса.
Конструкторы отличаются от обычных методов, и эти отличия проявляются и при использовании полиморфизма. Хотя конструкторы сами по себе не полиморфны (фактически они представляют собой статические методы, только ключевое слово static опущено), вы должны хорошо понимать, как работают конструкторы в сложных полиморфных иерархиях. Такое понимание в дальнейшем поможет избежать некоторых затруднительных ситуаций.
Порядок вызова конструкторов коротко обсуждался в главах 5 и 7, но в то время мы еще не рассматривали полиморфизм.
Конструктор базового класса всегда вызывается в процессе конструирования производного класса. Вызов автоматически проходит вверх по цепочке наследования, так что в конечном итоге вызываются конструкторы всех базовых классов по всей цепочке наследования. Это очень важно, поскольку конструктору отводится особая роль — обеспечивать правильное построение объектов. Производный класс обычно имеет доступ только к своим членам, но не к членам базового класса (которые чаще всего объявляются со спецификатором private). Только конструктор базового класса обладает необходимыми знаниями и правами доступа, чтобы правильно инициализировать свои внутренние элементы. Именно поэтому компилятор настаивает на вызове конструктора для любой части производного класса. Он незаметно подставит конструктор по умолчанию, если вы явно не вызовете конструктор базового класса в теле конструктора производного класса. Если конструктора по умолчанию не существует, компилятор сообщит об этом. (Если у класса вообще нет пользовательских конструкторов, компилятор автоматически генерирует конструктор по умолчанию.)