Эккель Брюс
Шрифт:
Неизменные аргументы
Java позволяет вам объявлять неизменными аргументы метода, объявляя их с ключевым словом final в списке аргументов. Это значит, что метод не может изменить значение, на которое указывает передаваемая ссылка:
II: reusing/FinalArguments.java II Использование final с аргументами метода
class Gizmo {
public void spinO {}
}
public class Final Arguments { void with(final Gizmo g) {
III g = new GizmoO; II запрещено -- g объявлено final
}
void without(Gizmo g) {
g = new GizmoO: II Разрешено -- g не является final g.spinO;
}
II void f(final int i) { i++, } II Нельзя изменять. II неизменные примитивы доступны только для чтения: int g(final int i) { return i + 1; } public static void main(String[] args) {
Final Arguments bf = new FinalArgumentsO;
bf .without(null): продолжение & bf with(niil 1),
}
} ///.-
Методы f и g показывают, что происходит при передаче методу примитивов с пометкой final: их значение можно прочитать, но изменить его не удастся.
Неизменные методы
Неизменные методы используются по двум причинам. Первая причина — «блокировка» метода, чтобы производные классы не могли изменить его содержание. Это делается по соображениям проектирования, когда вам точно надо знать, что поведение метода не изменится при наследовании.
Второй причиной в прошлом считалась эффективность. В более ранних реализациях Java объявление метода с ключевым словом final позволяло компилятору превращать все вызовы такого метода во встроенные (inline). Когда компилятор видит метод, объявленный как final, он может (на свое усмотрение) пропустить стандартный механизм вставки кода для проведения вызова метода (занести аргументы в стек, перейти к телу метода, исполнить находящийся там код, вернуть управление, удалить аргументы из стека и распорядиться возвращенным значением) и вместо этого подставить на место вызова копию реального кода, находящегося в теле метода. Таким образом устраняются издержки обычного вызова метода. Конечно, для больших методов подстановка приведет к «разбуханию» программы, и, скорее всего, никаких преимуществ от использования прямого встраивания не будет.
В последних версиях Java виртуальная машина выявляет подобные ситуации и устраняет лишние передачи управления при оптимизации, поэтому использовать final для методов уже не обязательно — и более того, нежелательно.
Спецификаторы final и private
Любой закрытый (private) метод в классе косвенно является неизменным (final) методом. Так как вы не в силах получить доступ к закрытому методу, то не сможете и переопределить его. Ключевое слово final можно добавить к закрытому методу, но его присутствие ни на что не повлияет.
Это может вызвать недоразумения, так как при попытке переопределения закрытого (private) метода, также неявно являющегося final, все вроде бы работает и компилятор не выдает сообщений об ошибках:
//• reusi ng/Fi nalOverri di ngll1usi on.java
// Все выглядет так, будто закрытый (и неизменный) метод
// можно переопределить, но это заблуждение.
import static net mindview.util Print.*,
class WithFinals {
// To же, что и просто private:
private final void f { printC'WithFinals fM), }
// Также автоматически является final
private void g { printC'WithFinals.g"), }
class OverridingPrivate extends WithFinals {
private final void f {
printC'OverridingPrivate fO").
}
private void g {
printC'OverridingPrivate g").
}
}
class 0verridingPrivate2 extends OverridingPrivate {
public final void f {
print("0verridingPrivate2 f").
}
public void g {
print("0verridingPrivate2 g").
}
public class FinalOverridingll1usion {
public static void main(String[] args) {
0verridingPrivate2 op2 = new 0verridingPrivate2;
op2 f;
op2.g;
// Можно провести восходящее преобразование-
OverridingPrivate op = op2;
// Но методы при этом вызвать невозможно.
//! op f.
//! op.g.
// И то же самое здесь-WithFinals wf = ор2. //! wf.fO, //! wf g;
}
} /* Output: 0verridingPrivate2.f
0verridingPrivate2.g */// ~
«Переопределение» применимо только к компонентам интерфейса базового класса. Иначе говоря, вы должны иметь возможность выполнить восходящее преобразование объекта к его базовому типу и вызвать тот же самый метод (это утверждение подробнее обсуждается в следующей главе). Если метод объявлен как private, он не является частью интерфейса базового класса; это просто некоторый код, скрытый внутри класса, у которого оказалось то же имя. Если вы создаете в производном классе одноименный метод со спецификатором public, protected или с доступом в пределах пакета, то он никак не связан с закрытым методом базового класса. Так как privat-метод недоступен и фактически невидим для окружающего мира, он не влияет ни на что, кроме внутренней организации кода в классе, где он был описан.