Философия Java3

Переменные от vl до VAL_3 поясняют смысл объявления ссылок с ключевым словом final. Как видно из метода main, объявление ссылки v2 как final еще не означает, что ее объект неизменен. Однако присоединить ссылку v2 к новому объекту не получится, как раз из-за того, что она была объявлена как final. Именно такой смысл имеет ключевое слово final по отношению к ссылкам. Вы также можете убедиться, что это верно и для массивов, которые являются просто другой разновидностью ссылки. Пожалуй, для ссылок ключевое слово final обладает меньшей практической ценностью, чем для примитивов.

Пустые константы

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

//: c06:BlankFinal .java // "Пустые" неизменные поля.

class Poppet {

private int i:

Poppet(int ii) { i = ii; }

}

public class BlankFinal {

private final int i = 0; // Инициализированная константа private final int j; // Пустая константа private final Poppet p; // Пустая константа-ссылка II Пустые константы НЕОБХОДИМО инициализировать // в конструкторе: public BlankFinalО {

j = 1; // Инициализация пустой константы р = new Poppet(l); // Инициализация пустой неизменной ссылки

}

public BlankFinal(int х) {

j = х; // Инициализация пустой константы р = new Poppet(x), // Инициализация пустой неизменной ссылки

}

public static void main(String[] args) { new BlankFinal О; new BlankFinal(47),

}

} ///:-

Значения неизменных (final) переменных обязательно должны присваиваться или в выражении, записываемом в точке определения переменной, или в каждом из конструкторов класса. Тем самым гарантируется инициализация полей, объявленных как final, перед их использованием.

Неизменные аргументы

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 f^M), }

// Также автоматически является 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 */// ~