Effective Java tmprogramming Language GuideJ o s h u a b lo c h

• Название: Effective Java tmprogramming Language GuideJ o s h u a b lo c h
• Дата: 03.04.2018
• Размер: 1.05 Mb.
• Имя файла: Blokh_Dzh_-_Java_Effektivnoe_programmirovanie.pdf
• Тип: Документы; #40178
• страница: 24 из 25

; // Состояние private boolean initialized = false;
public AbstractFoo(int x, int y) { initialize(x, y); }
/**
* Данный конструктор и следующий за ним метод позволяют методу * readObject в подклассе инициализировать наше внутреннее состояние */
protected AbstractFoo() { }
protected final void initialize(int x, int y) {
if (initialized)
throw new IllegalStateException(
"Already initialized");
this.x = x;
this.y = y;
// ... // Делает все остальное, что делал прежний конструктор initialized = true;
}
/**
Эти методы предоставляют доступ к внутреннему состоянию класса,
* и потому его можно сериализовать вручную, используя
* метод writeObject из подкласса */
202

protected final int getX() { return x; }
protected final int getY() { return y; }
// Должен вызываться для всех открытых методов экземпляра private void checkInit() throws IllegalStateException {
if (!initialized)
throw new IllegalStateException("Uninitialized");
}
// ... // Остальное опущено
}
Все методы в экземпляре AbstractFoo, прежде чем выполнять свою работу, должны вызывать checklnit. Тем самым гарантируется быстрое и четкое аварийное завершение этих методов в случае, если неудачно написанный подкласс не инициализировал соответствующий экземпляр. Имея этот механизм взамен прежнего, можно перейти к реализации сериалнзуемого подкласса import java.io.*;
public class Foo extends AbstractFoo implements Serializable {
private void readObject(ObjectInputStream s)
throws IOException, ClassNotFoundException {
s.defaultReadObject();
// Ручная десериализация и инициализация состояния суперкласса
int x = s.readInt();
int y = s.readInt();
initialize(x, y);
}
private void writeObject(ObjectOutputStream s)
throws IOException {
s.defaultWriteObject();
// Ручная сериализация состояния суперкласса
s.writeInt(getX());
s.writeInt(getY());
}
// Конструктор не использует никаких причудливых механизмов public Foo(int x, int y) { super(x, y); Внутренние классы статья 18) редко должны (если вообще должны) реализовывать интерфейс
Serializable. Для размещения ссылок на экземпляры контейнера (enclosing instance) и значений локальных переменных из окружения они
203

используют искусственные поля (synthetic field), генерируемые компилятором. Как именно эти поля соотносятся с декларацией класса, не конкретизируется. Не конкретизируются также названия анонимных и локальных классов. Поэтому выбор для внутреннего класса серилизованной формы, предлагаемой по умолчанию, плохое дизайнерское решение. Однако статический класс-член вполне может реализовывать интерфейс Serializable. Подведем итоги. Легкость реализации интерфейса е обманчива. Реализация интерфейса Serializable - серьезное обязательство, которое следует брать на себя с осторожностью, если только не предполагается выбросить класс после недолгого использования. Особое внимание требует класс, предназначенный для наследования. Для таких классов границей между реализацией интерфейса е в подклассах и его запретом является создание доступного конструктора без параметров. Это позволяет реализовать в подклассе интерфейсе, хотя и не является обязательным условием. Рассмотрите возможность использования специализированной bbс ер и али зова н ной формы bЕсли вы создаете класс в условиях дефицита времени, то, как правило, имеет смысл сконцентрировать усилия на построении самого лучшего АР. Иногда это означает создание "одноразовой" реализации, которая в следующей версии поменяется. Обычно это проблем не вызывает, однако если данный класс реализует интерфейс Serializable и использует при этом сериализованную форму, предоставленную по умолчанию, вам уже никогда не удастся полностью избавиться от этой временной реализации, иона всегда будет навязывать вам именно эту сериализованную форму. Это не теоретическая проблема. Такое уже происходило с несколькими классами из библиотек для платформы Java, такими как B1gInteger. Нельзя принимать сериализованную форму, предлагаемую по умолчанию, не обдумав как следует, устраивает ли она вас. Ваше решение должно быть взвешенным, приемлемым сточки зрения гибкости, производительности и правильности приложения. Вообще говоря, вы должны принимать сериализованную форму, используемую по умолчанию, только если она в значительной степени совпадает стой кодировкой, которую вы бы выбрали, если бы проектировали сериализованную форму сами,
Сериализованная форма представления объекта, предлагаемая по умолчанию,это довольно Эффективное физическое представление графа объектов, имеющего корнем данный объект. Другими словами, эта форма описывает данные, содержащиеся как в самом объекте, таки во всех доступных из него объектах. Она также отражает топологию взаимосвязи этих объектов. Идеальная же сериализованная форма, описывающая объект, содержит только представляемые им логические данные, От физического представления она не зависит,
204

Сериализованная форма, предлагаемая по умолчанию, по-видимому, будет приемлема в том случае, если физическое представление объекта равнозначно его логическому содержанию. Например, сериализованная форма, предлагаемая по умолчанию, будет правильной для следующего класса, который представляет имя человека
// Хороший кандидат для использования формы // предлагаемой по умолчанию
public class Name implements Serializable
/**
* Последнее имя (англ. ). Не должно быть пустым (non-null)
* @serial
*/
private String lastName;
/**
* Первое имя. Не должно быть пустым.
*'@serial
*/
private String firstName;
/**
* Средний инициал или '\uOOOO', если инициал отсутствует
* @serial
*/
private char middlelnitial;
// Остальное опущено Логически имя человека в английском языке состоит из двух строк, представляющих последнее и первое имя, а также из некоего символа, соответствующего среднему инициалу. Экземпляры полей в классе Name в точности воспроизводят этологическое содержание, Если вы решите принять сериализованную форму, предлагаемую по умолчанию, во многих случаях сохранение инвариантов и безопасность требуют реализации метода readObj ect. В случае с классом Name метод readObject мог бы гарантировать, что поля lastName и firstName не будут иметь значения null. Эта тема подробно рассматривается в статье 56. Заметим, что поля lastName, firstName и middlelnitial сопровождает комментарий к документации, хотя все они являются закры

ыми. Это необходимо поскольку эти закрытые поля определяют открытый АР сериализованную форму класса, а всякий открытый АР должен быть документирован. Наличие тега @serial говорит утилите Javadoc о том, что эту информацию необходимо поместить на специальную страницу, где описываются сериализованные формы.
205

Теперь рассмотрим класс, который представляет набор строк (забудем на минуту о том, что для этого лучше было бы взять в библиотеке одну из стандартных реализаций интерфейса List):
// Ужасный кандидат на использование сериализованной формы,
// предлагаемой по умолчанию
public class StringList implements Serializable {
private int size = 0; private Entry head = null; private static class Entry implements Serializable {
String data;
Entry next;
Entry previous; }
// Остальное опущено Логически этот класс представляет последовательность строк. Физически последовательность представлена им как дважды связный список. Если вы примите сериализованную форму, предлагаемую по умолчанию, она старательно отразит каждый элемент в этом связном списке, а также все связи между этими элементами в обоих направлениях. В случае, когда физическое представление объекта существенно отличается от содержащихся в нем логических данных, сериализованная форма, предлагаемая по умолчанию, имеет четыре недостатка Она навсегда связывает внешний
API класса сего текущим внутренним представлением. В приведенном примере закрытый класс StringList.Entry становится частью открытого
API. Даже если в будущей версии внутреннее представление StringList поменяется, он все равно должен будет получать на входе представление в виде связного списка и генерировать его жена выходе. Этот класс уже никогда не избавится от кода, необходимого для манипулирования связными списками, даже если он ими уже не пользуется. Она может занимать чрезвычайно много места. В приведенном примере в сериализованной форме без всякой на то надобности представлен каждый элемент связанного списка со всеми его связями. Эти элементы и связи являются всего лишь деталями реализации, нестоящими включения в сериализованную форму. Из-за того, что полученная форма слишком велика, ее запись на диск или передача посети будет выполняться слишком медленно.
206

Она может обрабатываться чрезвычайно долго. Логика сериализации не содержит информации о топологии графа объекта, а потому приходится выполнять дорогостоящий обход вершин графа. В приведенном Примере достаточно было просто идти по ссылкам next. Она может вызвать переполнение стека. Процедура сериализации, реализуемая по умолчанию, выполняет рекурсивный обход графа объектов, что может вызвать переполнение стека даже при обработке графов среднего размера. На моей машине к переполнению стека приводит сериализация экземпляра StringList с 1200 элементами. Количество элементов, вызывающее эту проблему, меняется в зависимости от реализации УМ. В некоторых реализациях этой проблемы вообще не существует. Правильная сериализованная форма для класса StringList - это количество строк в списке, за которым следуют сами строки. Это соответствует освобожденным от деталей физической реализации логическим данным, представляемым классом StringList. Приведем исправленный вариант StringList, содержащий методы writeObject и readObject, которые реализуют правильную сериализованную форму. Напомним, что модификатор transient указывает на то, что экземпляр поля должен быть исключен из сериализованной формы, применяемой по умолчанию
// Класс StringList справильной сериализованной
формой
public class StringList implements Serializable private transient int size = о private transient Entry head = null;
// Больwе нет реализации Serializablel
private static class Entry {
String data;
Entry next;
Entry previous;
}
// Добавляет указанную строку вконец списка
public void add(String s) { ... }
/**
* Сериализует данный экземпляр
StringList.
*
* @serialData Показывается размер списка (количество
* содержащихся в нем строк)
«tt>int
* элементы списка (каждый в виде
String
206

private void writeObject(ObjectOutputStream s) throw s IОЕхсерtion { s.defaultW riteObject();
s.w ritelnt(size);
// Выписываем все элементы в правильном порядке
for (Entry ее е = e.next) s.w riteObject(e.data);
}
private void readObject(ObjectlnputStream s) throw s IOException, Cl assNotFoundException {
s.defaultReadObject(); int size = s. readlnt();
// Считываем все элементы и вставляем
for (int i = 0; i < size; i++) add((String)s. readObject())
; }
// Остальное опускаем Заметим, что из метода writeObject вызывается defaultWriteObject, а из метода readObject делается вызов defaultReadObject, несмотря на то, что ни одно из полей класса StringList не попадает в сериализованную форму. Если все экземпляры полей имеют модификатор transient, то формально можно обойтись без вызова методов defaultWriteObject и defaultReadObject, но это не рекомендуется. Даже если все экземпляры полей имеют модификатор trаnsiеnt, вызов defaultWriteObject оказывает влияние на сериализованную форму, в результате чего значительно повышается гибкость сериализации. Полученная форма оставляет возможность в последующих версиях добавлять в форму новые экземпляры полей, сохраняя при этом прямую и обратную совместимость с предыдущими версиями. Так, если сериализовать экземпляр класса в более поздней версии, а десериализовать в более ранней версии, появившиеся поля будут проигнорированы. Если бы более ранняя версия метода readObject не вызывала метод defaultReadObject, десериализация закончилась бы инициированием StreamCorruptedException. Заметим также, что хотя метод writeObject является закрытым, он сопровождается комментариями к документации. Объяснение здесь тоже, что ив случае с комментариями для закрытых полей в классе
Name. Этот закрытый метод определяет сериализованную форму открытый API, а открытый API должен быть описан в документации. Как и тег @seria1 в случае с полями, тег @serialData для методов говорит утилите Javadoc о том, что данную информацию необходимо поместить на страницу с описанием сериализованных форм.
208

Что касается производительности, то при средней длине строки, равной десяти символам, сериализованная форма для исправленной версии StгiпgList будет занимать вдвое меньше места, чем в первоначальном варианте. На моей машине сериализация исправленного варианта StгiпgList при длине строк в десять символов выполняется примерно в два с половиной раза быстрее, чем сериализация первоначального варианта. 11 наконец, у исправленного варианта не возникает проблем с переполнением стека, а потому практически нет верхнего ограничения на размер StringList, для которого можно выполнить сериализацию.
Сериализованная форма, предлагаемая по умолчанию, плохо подходит для класса StringList, но есть классы, для которых она подходит еще меньше. Для StгiпgList сериализованная форма, применяемая по умолчанию, не имеет гибкости и работает медленно. Однако она является правильнои в том смысле, что в результате сериализации и десериализации экземпляра StringList получается точная копия исходного объекта, и все его инварианты будут сохранены. Но для любого объекта, чьи инварианты привязаны к деталям реализации, это не так. Например, рассмотрим случай с хэш-таблицей. Ее физическим представлением является набор сегментов, содержащих записи ключ/значение. Сегмент, куда будет помещена запись, определяется функцией, которая для представленного ключа вычисляет хэш-код. Вообще говоря, нельзя гарантировать, что в различных реализациях jVM эта функция будет одной и той же. В действительности нельзя даже гарантировать, что она будет оставаться той же самой, если одну и туже запускать несколько раз. Следовательно, использование для хэш-таблицы сериализованной формы, предлагаемой по умолчанию, может стать серьезной ошибкой сериализация и десериализация хэш-таблицы могут привести к созданию объекта, инварианты которого будут серьезно нарушены.
11спользуете вы или нет сериализованную форму, предлагаемую по умолчанию, каждый экземпляр поляне помеченный модификатором trаnsiеnt, будет сериализован при вызове метода defaultWriteObject. Поэтому каждое поле, которое можно не заносить в форму, нужно пометить этим модификатором. К таковым относятся избыточные поля, чьи значения можно вычислить по таким "первичным полям данных, как кэшированное значение хэша. Сюда также относятся поля, чьи значения меняются при повторном запуске JVM. Например, это может быть поле типа 10ng, в котором хранится указатель на местную' (native) структуру данных. Прежде чем согласиться на запись какого- либо поля в сериализованной форме, убедитесь в том, что его значение является частью логического состояния данного объекта. Если вы пользуетесь специальной сериализованной формой, большинство или даже все экземпляры полей нужно пометить модификатором trаnsiеnt, как в примере с классом
StringList. Если вы пользуетесь сериализованной формой, предлагаемой по умолчанию, и к тому же пометили одно или несколько полей как trаnsiеnt, помните о том, что при десериализации экземпляра эти поля получат значения по умолчанию п для полей ссылок на объекты, нуль для простых числовых полей и false для полей типа
209

boolean [JLS, 4.5.5]. Если для какого-либо из этих полей указанные значения неприемлемы, необходимо предоставить метод readObject, который вызывает метода затем восстанавливает приемлемые значения в полях, помеченных как transient (статья 56). Альтернативный подход заключается в том, чтобы отложить инициализацию этих полей до первого вызова. Независимо оттого, какую сериализованную форму вы выберете, в каждом сериализуемом классе, который выпишите, явным образом декларируйте serial version UID. Тем самым вы исключите этот идентификатор из числа возможных причин несовместимости (статья 54). Это также даст некоторый выигрыш в производительности. Если seriaL version UID не представлен, то при выполнении программы для его генерации потребуется выполнить трудоемкие вычисления. Для декларации д version UID добавьте в ваш класс строку private static final long serialVersionUID = raтdoтLoтgValue;
// Произвольное число типа long Неважно, какое значение вы выберете для randoтLongValиe. Общепринятая практика предписывает генерировать это число, запуская для класса утилиту serialver. Однако можно взять число просто из "воздуха. Если вам когда-нибудь захочется создать новую версию класса, которая несовместима с имеющимися версиями, достаточно будет поменять значение в этой декларации. В результате попытки десериализировать экземпляры, сериализованные в предыдущих версиях, будут заканчиваться инициированием исключения InvalidClassException. Подведем итоги. Если решено, что класс должен быть сериализуемым (статья 54), подумайте над тем, какой должна быть сериализованная форма. Форму, предлагаемую по умолчанию, используйте, только если она правильно описывает логическое состояние объекта. В противном случае создайте специальную сериализованную форму, которая надлежащим образом описывает этот объект. На разработку сериализованной формы для класса вы должны выделить не меньше времени, чем на разработку его методов, предоставляемых клиентам. Точно также, как из последующих версий нельзя изъять те методы класса, которые были доступны клиентам, нельзя изымать поля из сериализованной формы. Чтобы при сериализации сохранялась совместимость, эти поля должны оставаться в форме навсегда. Неверный выбор сериализованной формы может иметь постоянное отрицательное влияние на сложность и производительность класса. Метод должен создаваться с защитой В статье 24 представлен неизменяемый класс для интервалов времени, который содержит изменяемые закрытые поля даты. Чтобы сохранить свои инварианты и неизменяемость, этот класс создает резервную копию объектов Date в конструкторе и методах доступа. Приведем этот класс
210

import java.util.*;
import java.io.*;
public final class Period implements Serializable {
private final Date start;
private final Date end;