Философия Java3

Эккель Брюс

print("Создаем FinalData"); FinalData fd2 = new FinalData("fd2^M). print(fdl), print(fd2):

}

} /* Output.

fdl i4 = 15. INT 5 = 18 _Л

продолжение &

Создаем Final Data fdl: i4 = 15. INT_5 = 18 fd2: i4 = 13. INT_5 = 18 *///:-

Так как valueOne и VALUE_TWO являются примитивными типами со значениями, заданными на стадии компиляции, они оба могут использоваться в качестве констант времени компиляции, и принципиальных различий между ними нет. Константа VALUE_THREE демонстрирует общепринятый способ

определения подобных полей: спецификатор public открывает к ней доступ за пределами пакета; ключевое слово static указывает, что она существует в единственном числе, а ключевое слово final указывает, что ее значение остается неизменным. Заметьте, что примитивы final static с неизменными начальными значениями (то есть константы времени компиляции) записываются целиком заглавными буквами, а слова разделяются подчеркиванием (эта схема записи констант позаимствована из языка С).

Само по себе присутствие final еще не означает, что значение переменной известно уже на стадии компиляции. Данный факт продемонстрирован на примере инициализации i4 и INT_5 с использованием случайных чисел. Эта часть программы также показывает разницу между статическими и нестатическими константами. Она проявляется только при инициализации во время исполнения, так как все величины времени компиляции обрабатываются компилятором одинаково (и обычно просто устраняются с целью оптимизации). Различие проявляется в результатах запуска программы. Заметьте, что значения поля i4 для объектов fdl и fd2 уникальны, но значение поля INT_5 не изменяется при создании второго объекта FinalData. Дело в том, что поле INT_5 объявлено как static, поэтому оно инициализируется только один раз во время загрузки класса.

Переменные от 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 можно добавить к закрытому методу, но его присутствие ни на что не повлияет.