effective-java

KO | EN

gitlite — search

#javascript #hacktoberfest #react #typescript #llm #linux #macos #java #windows #awesome #cli #vue #mcp #ios

(★ 21)

Краткое содержание "JAVA. Эффективное программирование", 3-е издание, Джошуа Блох

effective-java 최신버젼 다운로드

최종 버전 다운로드 (.zip)

// repository documentation

Was this content helpful?

★ 0 (0 ratings)

# Краткое содержание "JAVA. Эффективное программирование", 3-е издание, Джошуа Блох

## Описание

Это мой конспект
книги ["JAVA. Эффективное программирование", 3-е издание, Джошуа Блох](https://www.williamspublishing.com/Books/978-5-6041394-4-8.html) (
сайт российского издательства).

[Репозиторий](https://github.com/jbloch/effective-java-3e-source-code/tree/master/src/effectivejava) с оригинальным
кодом из книги.

Если Вы автор и считаете, что данный конспект нарушает авторские права - прошу сообщить, я сделаю этот репозиторий
приватным.

Нашли опечатку/неточность? Пишите - разберемся.

[Связаться со мной](https://t.me/szachesov)

# 1. Содержание

- [1. Содержание](#1-содержание)
- [2. Создание и уничтожение объектов](#2-создание-и-уничтожение-объектов)
    - [2.1 Рассмотрите применение статических фабричных методов вместо конструкторов (Item 1)](#21-рассмотрите-применение-статических-фабричных-методов-вместо-конструкторов-item-1)
    - [2.2 При большом количестве параметров конструктора подумайте о проектном шаблоне Строитель (Item 2)](#22-при-большом-количестве-параметров-конструктора-подумайте-о-проектном-шаблоне-строитель-item-2)
    - [2.3 Получайте синглтон с помощью закрытого конструктора или типа перечисления (Item 3)](#23-получайте-синглтон-с-помощью-закрытого-конструктора-или-типа-перечисления-item-3)
    - [2.4 Обеспечивайте неинстанцируемость с помощью закрытого конструктора (Item 4)](#24-обеспечивайте-неинстанцируемость-с-помощью-закрытого-конструктора-item-4)
    - [2.5 Предпочитайте внедрение зависимостей жестко прошитым ресурсам (Item 5)](#25-предпочитайте-внедрение-зависимостей-жестко-прошитым-ресурсам-item-5)
    - [2.6 Избегайте создание излишних объектов (Item 6)](#26-избегайте-создание-излишних-объектов-item-6)
    - [2.7 Избегайте устаревших ссылок (Item 7)](#27-избегайте-устаревших-ссылок-item-7)
    - [2.8 Избегайте финализаторов и очистителей (Item 8)](#28-избегайте-финализаторов-и-очистителей-item-8)
    - [2.9 Предпочитайте try-with-recurse использованию try-finally (Item 9)](#29-предпочитайте-try-with-recurse-использованию-try-finally-item-9)
- [3. Методы, общие для всех объектов](#3-методы-общие-для-всех-объектов)
    - [3.1 Перекрывая equals, соблюдайте общий контракт (Item 10)](#31-перекрывая-equals-соблюдайте-общий-контракт-item-10)
    - [3.2 Всегда при перекрытии equals перекрывайте hashCode (Item 11)](#32-всегда-при-перекрытии-equals-перекрывайте-hashcode-item-11)
    - [3.3 Всегда перекрывайте toString (Item 12)](#33-всегда-перекрывайте-tostring-item-12)
    - [3.4 Перекрывайте метод clone осторожно (Item 13)](#34-перекрывайте-метод-clone-осторожно-item-13)
    - [3.5 Подумайте о реализации Comparable (Item 14)](#35-подумайте-о-реализации-comparable-item-14)
- [4 Классы и интерфейсы](#4-классы-и-интерфейсы)
    - [4.1 Минимизируйте доступность классов и интерфейсов (Item 15)](#41-минимизируйте-доступность-классов-и-интерфейсов-item-15)
    - [4.2 Используйте в открытых классах методы доступа, а не открытые поля (Item 16)](#42-используйте-в-открытых-классах-методы-доступа-а-не-открытые-поля-item-16)
    - [4.3 Минимизируйте изменяемость (Item 17)](#43-минимизируйте-изменяемость-item-17)
    - [4.4 Предпочитайте композицию наследованию (Item 18)](#44-предпочитайте-композицию-наследованию-item-18)
    - [4.5 Проектируйте и документируйте наследование, либо запрещайте его (Item 19)](#45-предпочитайте-композицию-наследованию-item-19-)
    - [4.6 Предпочитайте интерфейсы абстрактным классам (Item 20)](#46-предпочитайте-интерфейсы-абстрактным-классам-item-20)
    - [4.7 Проектируйте интерфейсы для потомков (Item 21)](#47-проектируйте-интерфейсы-для-потомков-item-21)
    - [4.8 Используйте интерфейсы только для определения типов (Item 22)](#48-используйте-интерфейсы-только-для-определения-типов-item-22)
    - [4.9 Предпочитайте иерархии классов дескрипторам классов (Item 23)](#49-предпочитайте-иерархии-классов-дескрипторам-классов-item-23)
    - [4.10 Предпочитайте статические классы-члены нестатическим (Item 24)](#410-предпочитайте-статические-классы-члены-нестатическим-item-24)
    - [4.11 Ограничивайтесь одним классом верхнего уровня на исходный файл (Item 25)](#411-ограничивайтесь-одним-классом-верхнего-уровня-на-исходный-файл-item-25)
- [5 Обобщенное программирование](#5-обобщенное-программирование)
    - [5.1 Не используйте сырые типы (Item 26)](#51-не-используйте-сырые-типы-item-26)
    - [5.2 Устраняйте предупреждение о непроверяемом коде (Item 27)](#52-устраняйте-предупреждение-о-непроверяемом-коде-item-27)
    - [5.3 Предпочитайте списки массивам (Item 28)](#53-предпочитайте-списки-массивам-item-28)
    - [5.4 Предпочитайте обобщенные типы (Item 29)](#54-предпочитайте-обобщенные-типы-item-29)
    - [5.5 Предпочитайте обобщенные методы (Item 30)](#55-предпочитайте-обобщенные-методы-item-30)
    - [5.6 Используйте ограниченные символы подстановки для повышения гибкости API (Item 31)](#56-используйте-ограниченные-символы-подстановки-для-повышения-гибкости-api-item-31)
    - [5.7 Аккуратно сочетайте обобщенные типы и переменное количество аргументов (Item 32)](#57-аккуратно-сочетайте-обобщенные-типы-и-переменное-количество-аргументов-item-32)
    - [5.8 Применяйте безопасные с точки зрения типов гетерогенные контейнеры (Item 33)](#58-применяйте-безопасные-с-точки-зрения-типов-гетерогенные-контейнеры-item-33)
- [6 Перечисления и аннотации](#6-перечисления-и-аннотации)
    - [6.1 Используйте перечисление вместо констант int (Item 34)](#61-используйте-перечисление-вместо-констант-int-item-34)
    - [6.2 Используйте поля экземпляра вместо порядковых значений (Item 35)](#62-используйте-поля-экземпляра-вместо-порядковых-значений-item-35)
    - [6.3 Используйте EnumSet вместо битовых полей (Item 36)](#63-используйте-enumset-вместо-битовых-полей-item-36)
    - [6.4 Используйте EnumMap вместо индексирования порядковыми номерами (Item 37)](#64-используйте-enummap-вместо-индексирования-порядковыми-номерами-item-37)
    - [6.5 Имитируйте расширяемые перечисления с помощью интерфейсов (Item 38)](#65-имитируйте-расширяемые-перечисления-с-помощью-интерфейсов-item-38)
    - [6.6 Предпочитайте аннотации схемам именования (Item 39)](#66-предпочитайте-аннотации-схемам-именования-item-39)
    - [6.7 Последовательно используйте аннотацию Override (Item 40)](#67-последовательно-используйте-аннотацию-override-item-40)
    - [6.8 Используйте интерфейсы-маркеры для определения типов (Item 41)](#68-используйте-интерфейсы-маркеры-для-определения-типов-item-41)
- [7 Лямбда-выражения и Stream API](#7-лямбда-выражения-и-stream-api)
    - [7.1 Предпочитайте лямбда-выражения анонимным классам (Item 42)](#71-предпочитайте-лямбда-выражения-анонимным-классам-item-42)
    - [7.2 Предпочитайте ссылки на методы лямбда-выражениям (Item 43)](#72-предпочитайте-ссылки-на-методы-лямбда-выражениям-item-43)
    - [7.3 Предпочитайте использовать стандартные функциональные интерфейсы (Item 44)](#73-предпочитайте-использовать-стандартные-функциональные-интерфейсы-item-44)
    - [7.4 Разумно используйте Stream API (Item 45)](#74-разумно-используйте-stream-api-item-45)
    - [7.5 Предпочитайте в потоках функции без побочных эффектов (Item 46)](#75-предпочитайте-в-потоках-функции-без-побочных-эффектов-item-46)
    - [7.6 Предпочитайте коллекции потокам в качестве возвращаемых типов (Item 47)](#76-предпочитайте-коллекции-потокам-в-качестве-возвращаемых-типов-item-47)
    - [7.7 Будьте внимательны при многопоточном использовании Stream API (Item 48)](#77-будьте-внимательны-при-многопоточном-использовании-stream-api-item-48)
- [8 Методы](#8-методы)
    - [8.1 Проверяйте корректность параметров (Item 49)](#81-проверяйте-корректность-параметров-item-49)
    - [8.2 При необходимости создавайте защитные копии (Item 50)](#82-при-необходимости-создавайте-защитные-копии-item-50)
    - [8.3 Тщательно проектируйте сигнатуры методов (Item 51)](#83-тщательно-проектируйте-сигнатуры-методов-item-51)
    - [8.4 Перезагружайте методы разумно (Item 52)](#84-перезагружайте-методы-разумно-item-52)
    - [8.5 Используйте методы с переменным количеством аргументов с осторожностью (Item 53)](#85-используйте-методы-с-переменным-количеством-аргументов-с-осторожностью-item-53)
    - [8.6 Возвращайте пустые массивы и коллекции, а не null (Item 54)](#86-возвращайте-пустые-массивы-и-коллекции-а-не-null-item-54)
    - [8.7 Возвращайте Optional с осторожностью (Item 55)](#87-возвращайте-optional-с-осторожностью-item-55)
    - [8.8 Пишите документирующие комментарии для всех открытых элементов API (Item 56)](#88-пишите-документирующие-комментарии-для-всех-открытых-элементов-api-item-56)
- [9 Общие вопросы программирования](#9-общие-вопросы-программирования)
    - [9.1 Минимизируйте область видимости локальных переменных (Item 57)](#91-минимизируйте-область-видимости-локальных-переменных-item-57)
    - [9.2 Предпочитайте циклы for для коллекции традиционным циклам for (Item 58)](#92-предпочитайте-циклы-for-для-коллекции-традиционным-циклам-for-item-58)
    - [9.3 Изучите и используйте возможности библиотек (Item 59)](#93-изучите-и-используйте-возможности-библиотек-item-59)
    - [9.4 Если вам нужны точные ответы, избегайте float и double (Item 60)](#94-если-вам-нужны-точные-ответы-избегайте-float-и-double-item-60)
    - [9.5 Предпочитайте примитивные типы упакованных примитивным типам (Item 61)](#95-предпочитайте-примитивные-типы-упакованных-примитивным-типам-item-61)
    - [9.6 Избегайте применения строк там, где уместнее другой тип (Item 62)](#96-избегайте-применения-строк-там-где-уместнее-другой-тип-item-62)
    - [9.7 Помните о проблемах производительности при конкатенации строк (Item 63)](#97-помните-о-проблемах-производительности-при-конкатенации-строк-item-63)
    - [9.8 Для ссылки на объекты используйте их интерфейсы (Item 64)](#98-для-ссылки-на-объекты-используйте-их-интерфейсы-item-64)
    - [9.9 Предпочитайте интерфейсы рефлексии (Item 65)](#99-предпочитайте-интерфейсы-рефлексии-item-65)
    - [9.10 Пользуйтесь машинно-зависимыми методами осторожно (Item 66)](#910-пользуйтесь-машинно-зависимыми-методами-осторожно-item-66)
    - [9.11 Оптимизируйте осторожно (Item 67)](#911-оптимизируйте-осторожно-item-67)
    - [9.12 Придерживайтесь общепринятых соглашений по именованию (Item 68)](#912-придерживайтесь-общепринятых-соглашений-по-именованию-item-68)
- [10 Исключения](#10-исключения)
    - [10.1 Используйте исключения только в исключительных ситуациях (Item 69)](#101-используйте-исключения-только-в-исключительных-ситуациях-item-69)
    - [10.2 Используйте для восстановления проверяемые исключения, а для программных ошибок - непроверяемые (Item 70)](#102-используйте-для-восстановления-проверяемые-исключения-а-для-программных-ошибок---непроверяемые-item-70)
    - [10.3 Избегайте ненужных проверяемых исключений (Item 71)](#103-избегайте-ненужных-проверяемых-исключений-item-71)
    - [10.4 Предпочитайте использовать стандартные исключения (Item 72)](#104-предпочитайте-использовать-стандартные-исключения-item-72)
    - [10.5 Генерируйте исключения, соответствующие абстракции (Item 73)](#105-генерируйте-исключения-соответствующие-абстракции-item-73)
    - [10.6 Документировать все исключения, которые может генерировать метод (Item 74)](#106-документировать-все-исключения-которые-может-генерировать-метод-item-74)
    - [10.7 Включайте в сообщения информацию о сбое (Item 75)](#107-включайте-в-сообщения-информацию-о-сбое-item-75)
    - [10.8 Добивайтесь атомарности сбоев (Item 76)](#108-добивайтесь-атомарности-сбоев-item-76)
    - [10.9 Не игнорируйте исключения (Item 77)](#109-не-игнорируйте-исключения-item-77)
- [11 Многопоточное программирование](#11-многопоточное-программирование)
    - [11.1 Синхронизируйте доступ к совместно используемым изменяемым данным (Item 78)](#111-синхронизируйте-доступ-к-совместно-используемым-изменяемым-данным-item-78)
    - [11.2 Избегайте излишней синхронизации (Item 79)](#112-избегайте-излишней-синхронизации-item-79)
    - [11.3 Предпочитайте исполнителей, задания и потоки данных потокам исполнения (Item 80)](#113-предпочитайте-исполнителей-задания-и-потоки-данных-потокам-исполнения-item-80)
    - [11.4 Предпочитайте утилиты параллельности методам wait и notify(Item 81)](#114-предпочитайте-утилиты-параллельности-методам-wait-и-notify-item-81)
    - [11.5 Документируйте безопасность с точки зрения потоков (Item 82)](#115-документируйте-безопасность-с-точки-зрения-потоков-item-82)
    - [11.6 Аккуратно применяйте отложенную инициализацию (Item 83)](#116-аккуратно-применяйте-отложенную-инициализацию-item-83)
    - [11.7 Избегайте зависимости от планировщика потоков (Item 84)](#117-избегайте-зависимости-от-планировщика-потоков-item-84)
- [12 Сериализация](#12-сериализация)
    - [12.1 Предпочитайте альтернативы сериализации Java (Item 85)](#121-предпочитайте-альтернативы-сериализации-java-item-85)
    - [12.2 Реализуйте интерфейс Serializable крайне осторожно (Item 86)](#122-реализуйте-интерфейс-serializable-крайне-осторожно-item-86)
    - [12.3 Подумайте о применении пользовательской сериализованной формы (Item 87)](#123-подумайте-о-применении-пользовательской-сериализованной-формы-item-87)
    - [12.4 Создавайте защищенные методы readObject (Item 88)](#124-создавайте-защищенные-методы-readobject-item-88)
    - [12.5 Для управления экземпляром предпочитайте типы перечислений методу readResolve (Item 89)](#125-для-управления-экземпляром-предпочитайте-типы-перечислений-методу-readresolve-item-89)
    - [12.6 Подумайте о применении прокси-агента сериализации вместо сериализованных экземпляров (Item 90)](#126-подумайте-о-применении-прокси-агента-сериализации-вместо-сериализованных-экземпляров-item-90)

# 2. Создание и уничтожение объектов

## 2.1 Рассмотрите применение статических фабричных методов вместо конструкторов (Item 1)

Плюсы:

- Они имеют имена
- Они не обязаны создавать новые объекты при каждом вызове
- Могу возвращать объект любого подтипа их возвращаемого типа
- Класс возращенного объекта может варьироваться от вызова к вызову в зависимости от входных параметров
- Класс возвращаемого объекта не обязан существовать во время разработки класса, содержащего метод

Минусы:

- Классы без открытых или защищенных конструкторов не могу порождать подклассы
- Трудно отличить от других статических методов

Распространенные статистические фабричные методы:

| **Название**                  | **Описание**                                                                                                 | **Пример**                                                   |
|-------------------------------|--------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------|
| **from**                      | преобразование типа                                                                                          | `Date d = Date.from(instant)`                                |
| **of**                        | метод агрегации                                                                                              | `Set<Rank> faceCards = EnumSet.of(JACK, QUEEN, KING)`        |
| **valueOf**                   | многословная альтернатива **from**, **of**                                                                   | `BigInteger prime = BigInteger.valueOf(Integer.MAX_VALUE)`   |
| **instance**, **getInstance** | возвращает экземпляр, описываемый параметрами, но о котором нельзя сказать, что имеет тоже значение          | `StackWalker luke = StackWalker.getInstance(options)`        |
| **create**, **newInstance**   | подобен **instance** или **getInstance**, но точно возвращает новый экземпляр                                | `Object newArray = Array.newInstance(classObject, arrayLen)` |
| **get**Type                   | подобен **getInstance**, но если фабричный метод находится в другом классе. Type - тип возвращаемого объекта | `FileStore fs = Files.getFileStore(path)`                    |
| **new**Type                   | подобен **newInstance**, но если фабричный метод находится в другом классе. Type - тип возвращаемого объекта | `BufferedReader br = Files.newBufferedReader(path)`          |
| type                          | краткая альтернатива **get**Type и **new**Type                                                               | `List<Complaint> litany = Collections.list(legacyLitany)`    |

## 2.2 При большом количестве параметров конструктора подумайте о проектном шаблоне Строитель (Item 2)

- Если конструктор или статические фабрики имеет большое количество параметров(4+), то лучше рассмотреть шаблон
  Строитель при создании объекта
- Код клиента проще для чтения и записи
- Безопаснее чем шаблон `JavaBeans` и может быть неизменяемым

_Реализация_:

```java

public class NutritionFacts {
    private final int servingSize;
    private final int servings;
    private final int calories;
    private final int fat;
    private final int sodium;
    private final int carbohydrate;

public static class Builder {
        // Обязательные параметры
        private final int servingSize;
        private final int servings;

// Опциональные параметры со значением по умолчанию
        private int calories = 0;
        private int fat = 0;
        private int carbohydrate = 0;
        private int sodium = 0;

public Builder(int servingSize, int servings) {
            this.servingSize = servingSize;
            this.servings = servings;
        }

public Builder calories(int val) {
            calories = val;
            return this;
        }

public Builder fat(int val) {
            fat = val;
            return this;
        }

public Builder carbohydrate(int val) {
            carbohydrate = val;
            return this;
        }

public Builder sodium(int val) {
            sodium = val;
            return this;
        }

public NutritionFacts build() {
            return new NutritionFacts(this);
        }
    }

private NutritionFacts(Builder builder) {
        servingSize = builder.servingSize;
        servings = builder.servings;
        calories = builder.calories;
        fat = builder.fat;
        sodium = builder.sodium;
        carbohydrate = builder.carbohydrate;
    }
}
```

_Код клиента:_
`NutritionFacts cocaCola=new NutritionFacts.Builder(240,8).calories(100).sodium(35).carbohydrate(27).build();`

## 2.3 Получайте синглтон с помощью закрытого конструктора или типа перечисления (Item 3)

Синглтон с полем `public final`:

```java
public class Elvis {
    public static final Elvis INSTANCE = new Elvis();

private Elvis() {
    }

public void singASong() {
    }
}

```

Плюсы:

- Из-за `public` поля API делает очевидным, что объект будет синглтом
- Простая реализация

_Синглтон со статической фабрикой:_

```java
    public class Elvis {
    private static final Elvis INSTANCE = new Elvis();

private Elvis() {
    }

public static Elvis getInstance() {
        return INSTANCE;
    }

public void singASong() {
    }
}

```

Плюсы:

- Можно изменить класс на не синглтон, не меняя его API
- Можно написать обобщенную фабрику синглтонов
- Можно использовать ссылку на метод, при использовании лямбды-выражения

Минусы этих реализаций:

- Можно вызвать конструктор с помощью рефлексии. Защита - добавить в конструктор генерацию исключения, при
  создании второго экземпляра.

Что бы сделать эти классы сереализуемым, необходимо пометить все поля `transient` и предоставить
метод `readResolve` ([Item 89](#125-для-управления-экземпляром-предпочитайте-типы-перечислений-методу-readresolve-item-89)).

```java
class Item3 {
    private Object readResolve() {
        // Возвращает истинный объект
        return INSTANCE;
    }
}

```

Синглтон-перечисление:

```java

public enum Elvis() {
    INSTANCE;

public void singASong() {
    }
}

```

Самый компактный способ, но не поддерживается наследование от класса, только реализация интерфейса.

## 2.4 Обеспечивайте неинстанцируемость с помощью закрытого конструктора (Item 4)

Это подходит для классов, который имеет только статистические методы и статистические поля (утильные классы).

Например:

- Группировка связанных методов над примитивами или массивами (`java.util.Arrays`)
- Группировка статистических методов и фабрики (`java.util.Collections`)
- Группировка методов в `final` - классе

```java
public class UtilityClass {
    private UtilityClass() {
        throw new AssertionError();
    }
}

```

## 2.5 Предпочитайте внедрение зависимостей жестко прошитым ресурсам (Item 5)

Не стоит использовать класс синглтон или утильный(статистический), если они зависят от ресурсов(объектов), поведение
которых влияют на них. И не стоит предоставлять создание ресурсов этим классам.
Лучше предавать ресурсы или их фабрики для создания, конструктору (или статистической фабрике, или строителю). Этот
подход называется **Внедрение зависимостей**, повышает гибкость, возможность повторного использования.

```java
public class SpellChecker {
    private final Lexicon dictionary;

public SpellChecker(Lexicon dictionary) {
        this.dictionary = Objects.requireNonNull(dictionary);
    }
}
```

## 2.6 Избегайте создание излишних объектов (Item 6)

1. Повторное использование неизменяемых объектов(пулл)

```java
class StringPool {
    void pool() {
        String n = new String("bikini"); // Плохо
        String p = "bikini"; // Хорошо
    }
}
```

При повторном использовании, в первом случае будет создаваться новый объект, во втором использоваться старый из пула.

Использование статических фабричных методов для неизменяемого
объекта ([Item 3](#23-получайте-синглтон-с-помощью-закрытого-конструктора-или-типа-перечисления-item-3)):

`Boolean.valueOf(String)`

2. Кэширование тяжеловесных объектов

```java
class RomanNumerals {
    // Можно повысить производительность
    static boolean isRomanNumeralSlow(String s) {
        return s.matches("^(?=.)M*(C[MD]|D?C{0,3})" + "(X[CL]|L?X{0,3})(I[XV]|V?I{0,3})$");
    }
}

```

```java
// Оптимально
class Item6 {
    private static final Pattern ROMAN =
            Pattern.compile("^(?=.)M*(C[MD]|D?C{0,3})" + "(X[CL]|L?X{0,3})(I[XV]|V?I{0,3})$");

static boolean isRomanNumeralFast(String s) {
        return ROMAN.matcher(s).matches();
    }
}

```

3. Предпочитайте примитивы классам оберткам и следите за непреднамеренной автоматической упаковкой

Но учтите:

- Не следует кэшировать легковесные объекты
- Избегайте создания собственного пула объектов. За исключением для тяжеловесных объектов, например подключение к базе
  данных

## 2.7 Избегайте устаревших ссылок (Item 7)

Лучший способ устранить устаревшие ссылки - выход ссылочной переменной из области видимости.

Источники утечки памяти:

- **Класс управляет своей памятью.** В данном случае подойдет обнуление ссылки.

```java
class Item7 {
    public pop() {
        if (size == 0) throw new EmptyStackException();
        Object result = elements[--size];
        elements[size] = null;
        return result;
    }
}

```

Обнуление ссылки не норма, а исключение из правил - не нужно обнулять ссылку для каждого объекта.

- **Утечка памяти в кэше.**
  Для очищения ссылок из кэша, можно использовать следующие решения.
  Использовать `WeakHashMap`, но только если желаемое время жизни записей кэша определяется внешним ссылками на ключ, а
  не значением. Можно очищать в кэше старые записи: использовать фоновые потоки(`ScheduledThreadPoolExecutor`), удаление
  старых ссылок после вставки новой или `LinkedHashMap` с методом `removeEldestEntry`.
- **Приложения в режиме ожидания(слушателя) и другие обратные вызовы.** Если клиенты регистрируют обратные вызовы, но
  позже не отменяют эту регистрацию, они могут накапливаться. Можно хранить на них только слабые ссылки используя
  `WeakHashMap`.

Утечки памяти могут накапливаться в системе годами. И обнаружить их можно тщательного ревю кода или/и с использованием
профилировщика.

## 2.8 Избегайте финализаторов и очистителей (Item 8)

- Финализаторы непредсказуемы, часто опасны и в общем случае не нужны
- Очистители (Java 9+) менее опасны, чем финализаторы, но столь же непредсказуемые, медленные и, в общем случае,
  ненужные
- С помощью финализатора или очистителя нельзя выполнять никакие операции, критичные по времени исполнения
- Никогда не следует обновлять состояние объекта в зависимости от финализатора или очистителя
- Серьезные проблемы производительности при использовании финализаторов или очистителей
- Финализаторы являются серьезной проблемой безопасности: они открывают ваш класс для атак финализаторов
- Генерация исключения в конструкторе должно быть достаточно для предотвращения существования объекта; однако при
  наличии финализатора это не так
- Для защиты классов, не являющихся финальными, от атак финализаторов напишите метод `finalize`, который не выполняет
  никаких действий
- Для класса, который инкапсулирует ресурсы, требующие освобождения, например файлы или потоки, лучше сделать его
  реализующий `AutoCloseable`. После этого его можно применять в
  конструкции `try-with-recurse` ([Item 9](#29-предпочитайте-try-with-recurse-использованию-try-finally-item-9))

## 2.9 Предпочитайте try-with-recurse использованию try-finally (Item 9)

Предпочитайте `try-with-recurse` применению `try-finally` при работе с ресурсами, которые должны быть закрыты.
Результирующий код получается короче и понятнее, а исключения, которые он генерирует, — более полезными.

```java
class Item9 {
    static void copy(String src, String dst) throws IOException {
        try (InputStream in = new InputStream(src);
             OutputStream out = new FileOutputStream(dst)) {
            byte[] buf = new byte[BUFFER_SIZE];
            int n;
            while ((n = in.read(buf)) >= 0) {
                out.write(buf, 0, n);
            }
        }
    }
}

```

Оператор `try-with-recurse` облегчает написание корректного кода с использованием ресурсов, которые должны быть закрыты,
что практически невозможно с помощью `try-finally`.

# 3. Методы, общие для всех объектов

## 3.1 Перекрывая equals, соблюдайте общий контракт (Item 10)

Когда не следует перекрывать:

- Каждый экземпляр класса уникален по своей природе
- У класса нет необходимости в проверке "логической эквивалентности"
- Суперкласс уже переопределяет `equals`, и поведение суперкласса подходит для данного класса
- Класс является закрытым или закрытым на уровне пакета, и вы уверены, что его метод `equals` никогда не будет
  вызываться

Класс имеет смысл перекрывать `equals`, когда для него определено понятие логической эквивалентности, которая не
совпадает с тождественностью объектов, а метод `equals` в суперклассе не перекрыт. Это происходит с классами
значениями(value class) - `String`, `Integer` и др.

Требования отношения эквивалентности:

- Рефлексивность: `x.equals(x)==true`
- Симметричность: `x.equals(y)==y.equals(x)`
- Транзитивность: `x.equals(y)==y.equals(z)==z.equals(x)`
- Непротиворечивость: `x.equals(y)==x.equals(y)==x.equals(y)==...`
- Отличный от `null`: `x.equals(null)==false`

Рецепт хорошего `equals`:

- Используйте оператор `==` для проверки того, что аргумент является ссылкой на данный объект
- Используйте оператор `instanceof` для проверки того, что аргумент имеет корректный тип
- Приводите аргумент к корректному типу
- Для каждого "важного" поля класса убедитесь, что значение этого поля в аргументе соответствует полю данного объекта

```java
class Item10 {
    @Override
    public boolean equals(Object o) {
        if (o == this) return true;

if (!(o instanceof PhoneNumber)) return false;

PhoneNumber pn = (PhoneNumber) o;
        return pn.lineNumber == lineNumber && pn.prefix == prefix && pn.areaCode == areaCode;
    }
}

```

Ещё предостережения:

- Всегда перекрывайте `hashCode` при перекрытии `equals`
- Не пытайтесь быть слишком умным
- Не подставляйте другой тип вместо `Object` в объявлении `equals`

## 3.2 Всегда при перекрытии equals перекрывайте hashCode (Item 11)

Вы обязанный перекрывать `hashCode` в каждом классе, перекрывающем `equals`.

Контракт `hashCode`:

- Для одно объекта, при многократном вызове `hashCode` должен всегда возвращать одно и то же целое число. При условии,
  что никакая информация, используемая при сравнении этого объекта с другими методом `equals`, не изменилась.
- Если два объекта равны по `equals`, то по `hashCode` тоже должны быть равны
- Если два объекта неравны по `equals`, то по `hashCode` могут быть равны или не равны. Но для оптимизации, лучше что бы
  были равны

Рецепт хорошего `hashCode`:

1. Объявить переменную `int result` и инициализировать её хеш-кодом для первого значащего поля объекта, описано в п. 2(
   а)
2. Для остальных значащих полей:

* Вычислите хеш-код типа `int` следующим образом:
    * Примитивный тип: `Type.hashCode(f)`, Type - клас обертка для примитивного типа
    * Ссылочный тип: если метод `equal` перекрыт и рекурсивно вызывается при использовании, то и `hashCode` вызывать
      рекурсивно. Если требуется сложное сравнение, то вычислить "каноническое представление" и вызвать `hashCode`. Если
      `null`, то 0.
    * Массив: вычислить для каждого объекта рекурсивно `hashCode` и объединить, а как в след. пункте. Если нет значащих
      элементов, то значение 0. Если все значащиеся, то `Arrays.hasCode`.
* Объедините хеш-код, вычисленные в предыдущем пункте: `result = 31 * result + с(предыдущий hashCode)`.

3. Верните `result`

```java
class Item11 {
    @Override
    public int hashCode() {
        int result = Short.hashCode(areaCode);
        result = 31 * result + Short.hashCode(prefix);
        result = 31 * result + Short.hashCode(lineNum);
        return result;
    }
}

```

И ещё:

- Не пытайтесь исключить значимые поля из вычисления хеш-кода для повышения производительности
- Не предоставляйте подробную спецификацию значения, возвращаемого `hashCode`, так, чтобы клиенты не могли от него
  зависеть; это позволит его изменить.

## 3.3 Всегда перекрывайте toString (Item 12)

Всегда перекрывайте метод `toString` в каждом инстансированном классе, если только он не переопределен в суперклассе.

Предоставление хорошей реализации метода `toString` делает ваш класс гораздо более удобным в использовании, а
использующею его систему - более простой в отладке.

Чтобы представлять интерес на практике, метод `toString` должен возвращать всю полезную информацию, которая содержится в
объекте.

Документируйте логику вывода `toString`, если даже не стандартизируете формат вывода.

Предоставляйте программный доступ ко всей информации в значении, возвращаемом методом `toString`.

## 3.4 Перекрывайте метод clone осторожно (Item 13)

Класс, реализующий `Cloneable`, предоставляет надлежащим образом функционирующий открытый метод `clone`. Иначе при
вызове клон возвратится `CloneNotSupportedException`.

Неизменяемые классы никогда не должны предоставлять метод `clone`, потому что это будет просто поощрением излишнего
копирования.

```java
class PhoneNumber implements Cloneable {
    // Clone method for class with no references to mutable state
    @Override
    public PhoneNumber clone() {
        try {
            return (PhoneNumber) super.clone();
        } catch (CloneNotSupportedException e) {
            throw new AssertionError();  // Can't happen
        }
    }
}

```

Если класс имеет поля, которые ссылаются на изменяемые объекты, то нужно вызвать `clone` рекурсивно для изменяемых
полей. Иначе поля клона будут ссылаться на объекты, на которые ссылаются поля объекта оригинала.

```java
class Stack implements Cloneable {
    @Override
    public Stack clone() {
        try {
            Stack result = (Stack) super.clone();
            result.elements = elements.clone();
            return result;
        } catch (CloneNotSupportedException e) {
            throw new AssertionError();
        }
    }
}

```

Архитектура `Cloneable` несовместима с нормальны использованием `final` - полей, ссылающихся на изменяемые объекты.
Возможно потребуется убрать `final`, что клонировать объект.

Метод `clone` никогда не должен вызывать перекрываемый метод для создаваемого клона.

Открытые методы `clone` должны опускать конструкцию `throws`, поскольку методы, не генерирующие проверяем исключения,
более просты в использовании.

При проектировании класса для наследования, он не должен реализовывать интерфейс `Cloneable`. Есть два варианта:
имитировать поведение `Object`, путем реализации корректного `clone` или как генерирующего исключение
`CloneNotSupportedException`.

Метод клонирования должен правильно быть синхронизирован.

Лучшие альтернативы для клонирования объектов:

1. Конструктор копирования
   `public Yum(Yum yum)`

2. Фабрика копий
   `public static Yum newInstance(Yum yum)`

Плюсы:

- Не полагается на сложный механизм создания объектов
- Не требует соблюдения слабо документированных соглашений
- Не конфликтует с использованием `final` - полей
- Не генерирует ненужные непроверяемые исключения
- Не требует преобразования объектов

Также данные подходы позволяют использовать для преобразования объектов `new TreeMap<>(new HashMap<>())`

## 3.5 Подумайте о реализации Comparable (Item 14)

Реализуя класс значения(value class), которое имеет упорядочение, обеспечивайте реализацию `Comparable`, чтобы его
экземпляры можно было легко сортировать, искать и использовать в коллекциях, основных на сравнениях.

Контракт метода `compareTo`:

- `x.compareTo(y) == - (y.compareTo(x))`
- если `x.compareTo(y) > 0 && y.compareTo(z) > 0`, тогда и `x.compareTo(z) > 0`
- если `x.compareTo(y) == 0`, тогда и `x.compareTo(z) == y.compareTo(z)`
- Рекомендуется, но не обязательно: `(x.compareTo(y)==0) == (x.equals(y))`

Если метод `compareTo` сталкивается с объектами разных типов, генерируйте исключение `ClassCastException`.

При сравнении значимых полей в `compareTo` следует избегать операторы `<` и `>`. Вместо этого использовать
статистические методы `compare` классов оберток примитивных типов(`Integer.compare` и др.) или методы конструирования
компаратора в интерфейсе`Comparator`(`Comparator.comparingInt` и др.).

# 4 Классы и интерфейсы

## 4.1 Минимизируйте доступность классов и интерфейсов (Item 15)

Хорошо спроектированный модуль скрывает все детали реализации, четко отделяя API от реализации.

Делайте класс или член класса как можно более недоступным.

Классы и интерфейсы верхнего уровня могу иметь два уровня доступа: по-умолчанию и открытые.
Если класс или интерфейс верхнего уровня, доступный лишь в пределах пакета и используется только в одном классе, нужно
рассмотреть превращения его в закрытый статический класс, вложенный только в тот класс, в котором он
используется ([Item 24](#410-предпочитайте-вложенный-статический-класс-вложенному-внутреннему-классу-item-24)).

Если какой-либо метод перекрывает метод суперкласса, то в подклассе он не может иметь более ограниченный доступ, чем в
суперклассе.

Поля класса должны иметь уровень доступа `private`.
Поля константы могут быть открыты `public static final`. Но если константа ссылается на изменяемый объект, то поле
обладает недостатками не `final` поля.

Массив ненулевой длинный всегда изменяемый, ошибка если объявлен как `public static final`.

В Java 9+ появилось два неявных модификатора, как часть модульной системы. Открытые и защищенные члены открытых классов
в неэкспортируемых пакетах дают два неявных уровня доступа, которые являются внутри модульными аналогами обычных
открытых и защищенных уровней. Данный модификаторы не так распространены и можно обойтись переупорядочиванием классов
внутри
пакета.

## 4.2 Используйте в открытых классах методы доступа, а не открытые поля (Item 16)

Минусы открытых полей:

- Они лишены преимуществ инкапсуляции
- Нельзя изменить представление класса, не изменив его API
- Нельзя обеспечить выполнение инвариантов и предпринимать дополнительных действий при обращении к полю

Если класс доступен за пределами пакета, следует обеспечить методы доступа. Но если класс доступен в пределах пакета или
является закрытым вложенным классом, то никакого ущерба от предоставления доступа к его полям данных не будет.

## 4.3 Минимизируйте изменяемость (Item 17)

Неизменяемый класс - это класс, вся информация которого записывается в момент создания объекта и остается неизменной в
течение всего времени существования. Их проще проектировать, реализовывать и использовать. Они менее подвержены ошибкам
и более безопасны.

Как сделать класс незаменяемым:

1. Не проставлять методы, которые изменяют состояние объекта - методы установки(mutator).
2. Гарантируйте невозможность расширения класса. Добавление классу ключевого слова `final`, есть и другие способы.
3. Объявите все поля как `final`
4. Объявите все поля как `private`
5. Обеспечьте монопольный доступ ко всем изменяемым компонентам. Если класс имеет поля, ссылающиеся на изменяемые
   объекты, клиенты класса не должны получить ссылки на эти объекты. Не инициализируйте эти поля ссылками на объект,
   которые предоставляют клиент. Делайте защитные
   копии ([Item 50](#82-при-необходимости-создавайте-защитные-копии-item-50)) в конструктора, методах доступа и
   методах `readObject` ([Item 88](#124-создавайте-защищенные-методы-readobject-item-88)).

```java
public final class Complex {
    private final double re;
    private final double im;

public Complex(double re, double im) {
        this.re = re;
        this.im = im;
    }

// Accessors with no corresponding mutators
    public double realPart() {
        return re;
    }

public double imaginaryPart() {
        return im;
    }

public Complex add(Complex c) {
        return new Complex(re + c.re, im + c.im);
    }

public Complex subtract(Complex c) {
        return new Complex(re - c.re, im - c.im);
    }

@Override
    public boolean equals(Object o) {
    }
}

```

Особенности неизменяемого класса:

- Неизменяемые объекты просты. Они могут находиться только в одном состоянии - с котором был создан.
- Неизменяемые объекты потокобезопасны и не нужна синхронизация.
- Неизменяемые объекты можно использоваться совместно.
- Можно создавать неизменяемые объекты через статическую
  фабрику ([Item 1](#21-рассмотрите-применение-статических-фабричных-методов-вместо-конструкторов-item-1)) и кешировать
  часто запрашиваемые объекты.
- Можно совместно использовать не только неизменяемые объекты, но и их внутреннее представление.
- Неизменяемые объекты образуют крупные строительные блоки для прочих объектов.
- Неизменяемые объекты обеспечивают атомарность.

Основным недостатком неизменяемых классов является то, они требуют отдельных объектов для каждого уникального значения.
И следствие снижение производительности.

Запретить наследование, помимо `final`, можно сделать его конструктор закрытым или доступным на уровне пакета и добавить
статистическую фабрику ([Item 1](#21-рассмотрите-применение-статических-фабричных-методов-вместо-конструкторов-item-1)).

```java
public class Complex {
    private final double re;
    private final double im;

private Complex(double re, double im) {
        this.re = re;
        this.im = im;
    }

public static Complex valueOf(double re, double im) {
        return new Complex(re, im);
    }
}

```

Данный подход позволяет использовать несколько классов реализации, доступных в пределах пакета. За пределами пакета,
неизменяемый класс является финальным.

Если класс невозможно сделать неизменяемым, нужно максимально ограничить изменяемость и видимость.

## 4.4 Предпочитайте композицию наследованию (Item 18)

Речь идет только о наследовании от другого класса, а не о реализации интерфейса.

Наследование нарушает инкапсуляцию:

- Реализация суперкласса может меняться от версии к версии, и, если это происходит,
  подкласс может перестать корректно работать, даже если его код останется нетронутым.
- В новых версиях суперкласса может появиться новый метод, который не будет учитываться в подклассах и может привести
  проблемы с безопасностью.

Композиция как альтернатива наследованию. В классе создать закрытое поле, которое будет содержать ссылку на экземпляр
существующего класса. Каждый метод экземпляра в новом классе вызывает соответсвующий метод содержащего в классе
экземпляра существующего класса, а затем возвращает полученный результат. Эта технология передачи (forwarding), а
методы - методы передачи (forwarding methods).

```java
// Wrapper class - uses composition in place of inheritance
public class InstrumentedSet<E> extends ForwardingSet<E> {
    private int addCount = 0;

public InstrumentedSet(Set<E> s) {
        super(s);
    }

@Override
    public boolean add(E e) {
        addCount++;
        return super.add(e);
    }

@Override
    public boolean addAll(Collection<? extends E> c) {
        addCount += c.size();
        return super.addAll(c);
    }

public int getAddCount() {
        return addCount;
    }
}

// Reusable forwarding class
public class ForwardingSet<E> implements Set<E> {
    private final Set<E> s;

public ForwardingSet(Set<E> s) {
        this.s = s;
    }

public void clear() {
        s.clear();
    }

public boolean contains(Object o) {
        return s.contains(o);
    }

public boolean isEmpty() {
        return s.isEmpty();
    }

public int size() {
        return s.size();
    }

public Iterator<E> iterator() {
        return s.iterator();
    }

public boolean add(E e) {
        return s.add(e);
    }

public boolean remove(Object o) {
        return s.remove(o);
    }

public boolean containsAll(Collection<?> c) {
        return s.containsAll(c);
    }

public boolean addAll(Collection<? extends E> c) {
        return s.addAll(c);
    }

public boolean removeAll(Collection<?> c) {
        return s.removeAll(c);
    }

public boolean retainAll(Collection<?> c) {
        return s.retainAll(c);
    }

public Object[] toArray() {
        return s.toArray();
    }

public <T> T[] toArray(T[] a) {
        return s.toArray(a);
    }

@Override
    public boolean equals(Object o) {
        return s.equals(o);
    }

@Override
    public int hashCode() {
        return s.hashCode();
    }

@Override
    public String toString() {
        return s.toString();
    }
}

```

У данного подхода мало недостатков, один из них `SELF problem`, остальные менее существенные.

Пользоваться наследованием можно, если между классом и суперклассом есть реальная связь типа и подтипа. Но даже в этом
случае применение наследование может сделать программу ненадежной, особенно если подкласс и суперкласс принадлежат к
разным пакетам, а сам суперкласс не был изначально предназначен для расширения.

## 4.5 Проектируйте и документируйте наследование, либо запрещайте его (Item 19)

Класс должен документировать, какие из методов он использует сам (self-use), которые могут быть переопределены. Для
каждого открытого или защищенного метода документация должна указывать: какие методы он вызывает, которые могу быть
переопределены; в какой последовательности; каким образом результаты их вызова влияют на дальнейшую работу.

Для создания более эффективных подклассов, суперкласс может предоставлять точки входа при внутренней обработке в виде
разумно выбранных защищенных методов.

Единственный способ протестировать класс, предназначенный для наследования - написать подклассы.
Необходимо протестировать класс путем написания подклассов до того, как он буде выпущен.

Конструкторы класса не должны вызывать методы, которые могут быть переопределены. Не напрямую и не косвенно.

Если родительский класс реализовывает интерфейс `Cloneable` или `Serializable`, то ни методу `clone`, ни
методу `readObject` не разрешается вызывать методы, которые могут быть переопределены, ни непосредственно, ни косвенно.
Также эти методы должны иметь модификатор доступа `protected`.

Если класс не предполагается для наследования, то лучше запретить наследование данного класса:

- Объявить как `final`
- Сделать все конструкторы закрытыми или доступные в пределах пакета, а вместо них использовать статистические фабрики.

## 4.6 Предпочитайте интерфейсы абстрактным классам (Item 20)

В Java разрешено только единичное наследование, это ограничение на абстрактные классы серьезно сдерживает их
использование в качестве определений типов.

Существующие классы можно легко приспособить для реализации нового интерфейса.

Интерфейсы идеально подходят для создания миксинов(класс, который может иметь дополнительное поведение).

Интерфейс позволяет создавать фреймворк неиерархического типа.

Интерфейс обеспечивают безопасное и мощное развитие функциональности с использованием
класса-оболочки ([Item 18](#44-предпочитайте-композицию-наследованию-item-18)).

Можно объединить преимущества интерфейсов и абстрактных классов, предоставляя абстрактный класс скелетной реализации,
сопутствующий интерфейсу.

```java
// Concrete implementation built atop skeletal implementation
public abstract class AbstractMapEntry<K, V> implements Map.Entry<K, V> {
  // Записи в изменяемом отображении должны перекрывать этот метод
  @Override
  public V setValue(V value) {
    throw new UnsupportedOperationException();
  }

// Реализует общий контракт Map.Entry.equals
  @Override
  public boolean equals(Object o) {
    if (o == this) return true;
    if (!(o instanceof Map.Entry)) return false;
    Map.Entry<?, ?> e = (Map.Entry) o;
    return Objects.equals(e.getKeyO, getKeyO) && Objects.equals(e.getValue(), getValue());
  }

// Реализует общий контракт Map.Entry.hashCode
  @Override
  public int hashCode() {
    return Objects.hashCode(getKey()) ^ Objects.hashCode(getValue());
  }

@Override
  public String toString() {
    return getKeyO + +getValue();
  }
}

```

Необходима документация скелетной реализации.

## 4.7 Проектируйте интерфейсы для потомков (Item 21)

В Java 8 у интерфейсов появились дефолтные методы. Но добавление новых методов к существующим интерфейсам сопряжено с
риском. Если добавлять дефолтные методы в существующий интерфейс, то не во всех реализациях интерфейса метод будет
работать корректно.

Не всегда возможно написать дефолтный метод, который поддерживает все инварианты всех мыслимых реализаций.

В присутствии дефолтных методов существующие реализации интерфейсов могут компилироваться без ошибок или предупреждений,
но сбоить во время выполнения.

## 4.8 Используйте интерфейсы только для определения типов (Item 22)

Интерфейс следует использовать в качестве определения типа, который может быть использован для ссылки на экземпляры
класса.

Не следует использовать интерфейс констант:

```java
// Constant interface antipattern. Don't do it !
public interface PhysicalConstants {
    static final double AVOGADROS_NUMBER = 6.022_140_857e23;
    static final double BOLTZMAN_CONSTANT = 1.380_648_52e-23;
}

```

Лучше использовать утильный класс констант:

```java
public class PhysicalConstants {
    private PhysicalConstants() {
    } // Prevents instantiation

public static final double AVOGRADOS_NUMBER = 6.02214199e23;
    public static final double BOLTZAN_CONSTANT = 1.3806503e-23;
    public static final double ELECTRON_MASS = 9.10938188e-31;
}

```

## 4.9 Предпочитайте иерархии классов дескрипторам классов (Item 23)

Поле класса _дескриптор_ - указывает разновидность класса, который может находиться в разных состояниях.

Классы с дескрипторами многословны, склонны к ошибкам и неэффективны.

Применение дескрипторов является лишь бледным подобием иерархии классов. И лучше задуматься над рефакторингом.

## 4.10 Предпочитайте вложенный статический класс вложенному внутреннему классу (Item 24)

Виды классов внутри других классов(nested class) в Java:

- Вложенный статический класс(static member class)
- Вложенный внутренний класс(nonstatic member class)
- Анонимный класс(anonymous class)
- Локальный класс(local class)

Алгоритм подбора вида класса:

* Если класс внутри другого класса должен быть виден за пределами метода или он слишком длинный, для размещения в
  границах метода, используйте вложенный класс(static или nonstatic).
    * Если каждому экземпляру вложенного необходима ссылка на включающий его экземпляр, делайте его внутренним классом(
      nonstatic member class)
    * В остальных случаях статистический(static member class)
* Если класс находится внутри метода и нужно создавать экземпляр в одном месте программы и имеется тип для этого
  класса - анонимный класс(anonymous class)
* В остальных случаях локальный(local class)

## 4.11 Ограничивайтесь одним классом верхнего уровня на исходный файл (Item 25)

Никогда не размещайте несколько классов верхнего уровня или интерфейсов в одни исходном файле. Это гарантирует, что не
будет нескольких определений одного класса во время компиляции.

# 5 Обобщенное программирование

## 5.1 Не используйте сырые типы (Item 26)

Основная терминология

| **Термин**                                | **Пример**                         | **Item**                                                                                     |
|-------------------------------------------|------------------------------------|----------------------------------------------------------------------------------------------|
| Параметризованный тип                     | `List<String>`                     | [26](#51-не-используйте-сырые-типы-item-26)                                                  |
| Актуальный параметр типа                  | `String`                           | [26](#51-не-используйте-сырые-типы-item-26)                                                  |
| Обобщенный тип                            | `List<E>`                          | [26](#51-не-используйте-сырые-типы-item-26), [29](#54-предпочитайте-обобщенные-типы-item-29) |
| Формальный параметр типа                  | `E`                                | [26](#51-не-используйте-сырые-типы-item-26)                                                  |
| Неограниченный тип с символом подстановки | `List<?>`                          | [26](#51-не-используйте-сырые-типы-item-26)                                                  |
| Сырой тип                                 | `List`                             | [26](#51-не-используйте-сырые-типы-item-26)                                                  |
| Ограниченный параметр типа                | `<E extends Number>`               | [29](#54-предпочитайте-обобщенные-типы-item-29)                                              |
| Рекурсивно ограниченный тип               | `<T extends Comparable<T>>`        | [30](#55-предпочитайте-обобщенные-методы-item-30)                                            |
| Ограниченный тип с символом подстановки   | `List<? extends Number>`           | [31](#56-используйте-ограниченные-символы-подстановки-для-повышения-гибкости-api-item-31)    |
| Обобщенный метод                          | `static <E> List<E> asList(E[] a)` | [30](#55-предпочитайте-обобщенные-методы-item-30)                                            |
| Токен типа                                | `String.class`                     | [33](#58-применяйте-безопасные-с-точки-зрения-типов-гетерогенные-контейнеры-item-33)         |

Использование сырых типов может привести к ошибке только во время выполнения, по этому не рекомендуется их использовать.
Они оставлены для обратной совместимости.

```java
    private final Collection stamps =...;

stamps.

add(new Coin(...)); //Erroneous insertion. Does not throw any error

Stamp s = (Stamp) stamps.get(i); // Throws ClassCastException when getting the Coin
```

```java
    private final Collection<Stamp> stamps =...;

stamps.

add(new Coin()); // Compile time error. Coin can not be add to Collection<Stamp>

Stamp s = stamps.get(i); // No need casting
```

Правила образования подтипов для обобщенных типов: `List<String>` является подтипом сырого `List`, но не является
подтипом `List<Object>`. Теряется безопасность типов при использовании сырых типов, но не при использовании
параметризованных типов типа `List<Object>`.

Если фактический параметр типа не известен, то в качестве альтернативы для несформированного типа можно использовать
неограниченный тип с символом подстановки, например `Collection<?>`. Данный подход безопасней, поскольку в данную
коллекцию нельзя поместить любой элемент(кроме `null`), а сырой тип можно.

Исключения, когда можно использовать сырые типы:

1. Необходимо использовать несформированные типы в литералах классов: `List.class`, `String[].class` и `int.class`
   разрешены, а `List<String>.class` и `List<?>.class` - нет.
2. Использование оператора `instanceof` с обобщенными типами `if(o instanceof Set){Set<?> = (Set<?>)o;}`

## 5.2 Устраняйте предупреждение о непроверяемом коде (Item 27)

При использовании обобщенных элементов, можно столкнуться с предупреждением компилятора:

- о непроверяемом приведении
- о непроверяемом вызове метода
- о непроверяемом параметризованном типе с переменным количеством аргументов
- о непроверяемом преобразовании

Следует устранять все предупреждения о непроверяемом коде, какие можно устранить!

Если нельзя устранить предупреждения, но есть уверенность, что код, о котором предупреждает компилятор, безопасен, то
тогда(и только тогда!) можно скрыть предупреждения с помощью аннотации `@SupressWarnings("unchecked")`.

Всегда используйте аннотацию `@SupressWarnings` в наименьшей возможной области видимости.

Каждый раз при использовании `@SupressWarnings("unchecked")` нужно добавлять комментарий с пояснением, почему в данном
случае этот код безопасен.

## 5.3 Предпочитайте списки массивам (Item 28)

Отличия массивов от списков:

1. Массивы **ковариантны** - если `Sub` является подтипом `Super`, то `Sub[]` является подтипом `Super[]`. Обобщенные
   типы **инвариантны** - для двух различных типов `Type1` и `Type2` тип `List<Type1>` не является ни подтипом,
   ни супертипом `List<Type2>`.

2. Массивы являются типами, доступными во время выполнения программы. Обобщенные типы, реализуются с использованием
   затирания, то есть тип доступен во время компиляции, но во время исполнения неизвестен.

С учетом данных отличий, массивы обеспечивают безопасность времени выполнения с точки зрения типов, но не безопасность
типов при компиляции, и наоборот.

```java
class Item27 {
    void method27() {
        // Fails at runtime
        Object[] objectArray = new Long[1];
        objectArray[0] = "I don't fit in"; // Throws ArrayStoreException

// Won't compile
        List<Object> ol = new ArrayList<Long>(); // Incompatible types
        ol.add("I don't fit in");
    }
}

```

Из-за этих отличий нельзя перемешивать листы и массивы. Нельзя создавать подобные
элементы: `List<E>[]`, `new List<String>[]`, `new E[]`.

## 5.4 Предпочитайте обобщенные типы (Item 29)

Обобщенные типы безопаснее и проще в использовании, чем типы, которые требует приведений в клиентском коде. При
разработке новых типов убедитесь, что они могут быть использованы без таких приведений.

## 5.5 Предпочитайте обобщенные методы (Item 30)

Обобщенные методы, подобно обобщенным типам, безопаснее и проще в использовании, чем методы требующие от своих клиентов
использовать явные приведения входных параметров и возвращаемых значений.

Для метода сравнения объектов в коллекции, каждый объект должен быть сопоставим с любым другим её элементом. Этом можно
сделать с помощью рекурсивного ограничения `<E extends Comparable<E>>`.

## 5.6 Используйте ограниченные символы подстановки для повышения гибкости API (Item 31)

Поскольку параметризованные типы являются инвариантными, то невозможно в коллекцию `List<Nubmer>` вставить
объект `Integer` используя только формальный параметр типа `E`.

```java
class Item31 {
    public void pushAll(Iterable<E> src) {
        for (E e : src)
            puhs(e);
    }

public static void main(String[] args) {
        // Integer is a subtype of Number
        Stack<Number> numberStack = new Stack<Number>();
        Iterable<Integer> integers =...;
        numberStack.pushAll(integers); //Error message here: List<Integer> is not a subtype of List<Number>
    }
}
```

Что бы это было возможно, можно использовать ограниченный символ подстановки

Producer:

```java
class Item31 {
    // We want to push in everything that is E or inherits E
    public void pushAll(Iterable<? extends E> src) {
        for (E e : src) {
            push(e);
        }
    }
}

```

В данном случае параметризованный тип является производителем(producer). Также параметризованный тип может быть
потребителем(consumer), например получить объекты.

Consumer:

```java
class Item31 {
    public void popAll(Collection<? super E> dst) {
        while (!isEmpty()) dst.add(pop());
    }
}

```

Правило **PECS** - producer-extends, consumer-super

Не используйте ограниченные типы с символами подстановки в качестве возвращаемых типов. Пользователь данного элемента не
должен думать о типах символов подстановки.

`Comparable` и `Comparators` всегда потребители. Используйте `Comparable<? super T>` и `Comparator<? super T>`.

Если параметр типа появляется в объявлении метода только один раз, его следует заменить символом подстановки:

```java
public static <E> void swap(List<E> list, int i, int j)

public static void swap(List<?> list, int i, int j) //Более предпочтительный способ
```

## 5.7 Аккуратно сочетайте обобщенные типы и переменное количество аргументов (Item 32)

Следует помнить, что методы с переменным количеством аргументов и обобщенные типы взаимодействуют не очень хорошо,
потому что параметр переменной длины представляет собой утечку абстракции, построенную поверх массива, а правила типов
для массивов отличаются от правил для обобщенных типов.

Если метод вызывается с переменным числом параметров, выведение типов которых недоступно во время выполнения, компилятор
выдает предупреждение для такого вызова.

Опасно хранить значение в обобщенном массиве-параметре переменной длины.

```java
public class Dangerous {
    // Mixing generics and varargs can violate type safety!
    static void dangerous(List<String>... stringLists) {
        List<Integer> intList = List.of(42);
        Object[] objects = stringLists;
        objects[0] = intList; // Heap pollution
        String s = stringLists[0].get(0); // ClassCastException
    }
}

```

Но методы с переменным количеством параметров обобщенных или параметризованных типов могут быть весьма полезны на
практике, поэтому разработчики языка решили оставить эту несогласованность `Arrays.asList(T... a)`, `Collections.addAll(
Collection<? super T c, T... elements>)` и `EnumSet.of(E first, E... rest)`.

Обобщенный метод с переменным количеством аргументов безопасен, если:

1. Он ничего не сохраняет в массиве параметра переменной длины;
2. Он не делает массив (или его клон) видимым ненадежному коду.

Аннотация `@SafeVarargs` представляет собой обещание безопасности с точки зрения типов от автора метода. Используйте
`@SafeVarargs` с каждым методом с параметром переменной длины обобщенного или параметризованного типа, если гарантируете
безопасность.

## 5.8 Применяйте безопасные с точки зрения типов гетерогенные контейнеры (Item 33)

Использование обобщенных типов ограничивает фиксированным количествам параметров типа в контейнере. Например,
коллекции `Set<E>` нельзя сделать произвольное количество параметров типа `Set<E...>`.

Можно это обойти, помещая параметр типа в ключ, а не в контейнер.

```java

public class Favorites {
    private Map<Class<?>, Object> favorites = new HashMap<Class<?>, Object>();

public <T> void putFavorites(Class<T> type, T instance) {
        if (type == null)
            throw new NullPointerException("Type is null");
        favorites.put(type, type.cast(instance));//runtime safety with a dynamic cast
    }

public <T> getFavorite(Class<T> type) {
        return type.cast(favorites.get(type));
    }
}

```

# 6 Перечисления и аннотации

## 6.1 Используйте перечисление вместо констант int (Item 34)

Тип перечисления(enum) - это классы, которые экспортируют по одному экземпляру для каждой константы перечисления,
используя открытое статическое финальное поле.

До того как типы перечисление появились в языке Java, был распространен шаблон перечисления int(int enum pattern).
Данный способ не обеспечивает ни безопасности с точки зрения типов, ни выразительности. Данный шаблон больше не
рекомендуется. Так же как и шаблон перечисления String(String pattern enum), который к тому же не производительный.

Чтобы связать данные с константами причисления, следует объявить поля экземпляров и написать конструктор, который
получает данные и сохраняет их в поле. Перечисления неизменяемые, все поля должны
быть `final`([Item 17](#43-минимизируйте-изменяемость-item-17)). Также желательно их сделать `private`.

```java
public enum Planet {
    MERCURY(3.302e+23, 2.439e6),
    VENUS(4.869e+24, 6.052e6);
    // ...

private final double mass; // In kilograms
    private final double radius; // In meters
    private final double surfaceGravity; // In m / s^2

// Universal gravitational constant in m^3 / kg s^2
    private static final double G = 6.67300E-11;

// Constructor
    Planet(double mass, double radius) {
        this.mass = mass;
        this.radius = radius;
        surfaceGravity = G * mass / (radius * radius);
    }

public double mass() {
        return mass;
    }

public double radius() {
        return radius;
    }

public double surfaceGravity() {
        return surfaceGravity;
    }

public double surfaceWeight(double mass) {
        return mass * surfaceGravity; // F = ma
    }
}

```

Если применение `enum` связано с определенными классами верхнего уроня, оно должно быть классом-членом класса верхнего
уровня ([Item 24](#410-предпочитайте-вложенный-статический-класс-вложенному-внутреннему-классу-item-24)).

Можно связать поведение с константами. Для этого нужно объявить абстрактный метод в типе перечисления и перекрыть его
конкретным методом для каждой константы в теле класса, зависимого от константы(constant-specific class body). Такие
методы известны как реализации методов, зависимых от констант(constant-specific method implementations).

```java
public enum Operation {
    PLUS("+") {
        public double apply(double x, double y) {
            return x + y;
        }
    },
    MINUS("-") {
        public double apply(double x, double y) {
            return x - y;
        }
    },
    TIMES("*") {
        public double apply(double x, double y) {
            return x * y;
        }
    },
    DIVIDE("/") {
        public double apply(double x, double y) {
            return x / y;
        }
    };

private final String symbol;

Operation(String symbol) {
        this.symbol = symbol;
    }

@Override
    public String toString() {
        return symbol;
    }

public abstract double apply(double x, double y);

// Implementing a fromString method on an enum type (Page 164)
    private static final Map<String, Operation> stringToEnum =
            Stream.of(values()).collect(
                    toMap(Object::toString, e -> e));

// Returns Operation for string, if any
    public static Optional<Operation> fromString(String symbol) {
        return Optional.ofNullable(stringToEnum.get(symbol));
    }

public static void main(String[] args) {
        double x = Double.parseDouble(args[0]);
        double y = Double.parseDouble(args[1]);
        for (Operation op : Operation.values())
            System.out.printf("%f %s %f = %f%n",
                    x, op, y, op.apply(x, y));
    }
}
```

Применения `switch` к `enum` опасно с точки зрения поддержки и менее гибко. Альтернатива - использования
перечисления-стратегии.

```java
enum PayrollDay {
    MONDAY,
    TUESDAY,
    WEDNESDAY,
    THURSDAY,
    FRIDAY,
    SATURDAY(WEEKEND),
    SUNDAY(WEEKEND);

private final PayType payType;

PayrollDay() {
        this(WEEKDAY); // default
    }

PayrollDay(PayType payType) {
        this.payType = payType;
    }

int pay(int minutesWorked, int payRate) {
        return payType.pay(minutesWorked, payRate);
    }

// The strategy enum type
    enum PayType {
        WEEKDAY {
            int overtimePay(int minsWorked, int payRate) {
                return minsWorked <= MINS_PER_SHIFT ? 0 : (minsWorked - MINS_PER_SHIFT) * payRate / 2;
            }
        },
        WEEKEND {
            int overtimePay(int minsWorked, int payRate) {
                return minsWorked * payRate / 2;
            }
        };

abstract int overtimePay(int mins, int payRate);

private static final int MINS_PER_SHIFT = 8 * 60;

int pay(int minsWorked, int payRate) {
            int basePay = minsWorked * payRate;
            return basePay + overtimePay(minsWorked, payRate);
        }
    }

public static void main(String[] args) {
        for (PayrollDay day : values()) System.out.printf("%-10s%d%n", day, day.pay(8 * 60, 1));
    }
}

```

Конструкция `switch` с перечислениями хорошо подходит для дополнения типов перечислений поведением, зависимым от
констант.

```java
public class Inverse {
    public static Operation inverse(Operation op) {
        switch (op) {
            case PLUS:
                return Operation.MINUS;
            case MINUS:
                return Operation.PLUS;
            case TIMES:
                return Operation.DIVIDE;
            case DIVIDE:
                return Operation.TIMES;

default:
                throw new AssertionError("Unknown op: " + op);
        }
    }
}

```

Используйте перечисления всегда, когда требуется набор констант, члены которых известны во время компиляции.

## 6.2 Используйте поля экземпляра вместо порядковых значений (Item 35)

Никогда не выводите значение, связанное с перечислением, из его порядкового номера; вместо этого храните его в поле
экземпляра.

Лучше так не делать:

```java
public enum Ensemble {
    SOLO,
    DUET,
    TRIO;

public int numberOfMusicians() {
        return ordinal() + 1;
    }
}

```

Так можно:

```java
public enum Ensemble {
    SOLO(1), DUET(2), TRIO(3);

private final int numberOfMusicians;

Ensemble(int size) {
        this.numberOfMusicians = size;
    }

public int numberOfMusicians() {
        return numberOfMusicians;
    }
}

```

## 6.3 Используйте EnumSet вместо битовых полей (Item 36)

До появления `enum`, если элементы перечисляемого типа использовались в коллекциях, то применялась схема битовых полей.

Лучшая альтернатива использовать коллекцию `EnumSet`, которая объединяет в себе кратность и производительность битовых
полей, со всем преимуществами `enum`.

## 6.4 Используйте EnumMap вместо индексирования порядковыми номерами (Item 37)

Используйте `EnumMap`, если требуется сгруппировать объекты по элементам перечисления.

```java
class Plant {
    Map<Plant.LifeCycle, Set<Plant>> plantsByLifeCycle =
            Arrays.stream(garden)
                    .collect(groupingBy(p -> p.lifeCycle, () -> new EnumMap<>(LifeCycle.class), toSet()));
}

```

Если представление является многомерным, используйте `EnumMap<...,EnumMap<...>>`.

## 6.5 Имитируйте расширяемые перечисления с помощью интерфейсов (Item 38)

Классы `enum` невозможно сделать расширяемым, потому что каждый класс неявно наследуется от класса `Enum<E>`. Но можно
имитировать расширение с помощью реализации интерфейса.

```java
public interface Operation {
    double apply(double x, double y);
}

public enum BasicOperation implements Operation {
    PLUS("+") {
        public double apply(double x, double y) {
            return x + y;
        }
    };

private final String symbol;

BasicOperation(String symbol) {
        this.symbol = symbol;
    }
}

public enum ExtendedOperation implements Operation {
    EXP("^") {
        public double apply(double x, double y) {
            return Math.pow(x, y);
        }
    };

private final String symbol;

ExtendedOperation(String symbol) {
        this.symbol = symbol;
    }
}

```

Экземпляры этих типов могут использовать везде, где могут использовать экземпляры базового типа перечисления.

## 6.6 Предпочитайте аннотации схемам именования (Item 39)

Для указания элементов, которые требуют специальной обработки исторически используется схема именования.
Например, до 4 версии `JUnit` требовалось начинать названия метода со слова `test...`.

Минусы данного подхода:

- Возможны опечатки наименования, при этом обработчик не будет жаловаться. Например, `tset`.
- Нет понятного способа определения, что схемы именования используются только в соответствующих элементах программы.
  Например, назвать класс начиная со слова `Test...`, в надежде, что методы тестов сработают, но это не так.
- Нет хорошего способа связать значения параметров с элементами программы. Например, нужно указать, чтобы тест
  обрабатывал конкретное исключение.

Использование аннотаций позволяет помечать элементы, которые требуют специальной обработки и не обладают теми же
недостатками схемы именования. Начиная с версии 4 `JUnit` используется аннотация `@Test` (аннотация-маркер) для методов
тестов.

Обязательные параметры аннотации:

Тип хранения (`@Retention(RetentionPolicy.RUNTIME)`)

| **Название** | **Описание**                                                         |
|--------------|----------------------------------------------------------------------|
| SOURCE       | Используется только при написании класса, отбрасывается компилятором |
| CLASS        | Обрабатывается во время компиляции, но игнорируется JVM              |
| RUNTIME      | Обрабатывается во время компиляции и JVM                             |

Тип возможного использования (`@Target(ElementType.METHOD)`)

| **Название**    | **Описание**            |
|-----------------|-------------------------|
| ANNOTATION_TYPE | Другая аннотация        |
| CONSTRUCTOR     | Конструктор класса      |
| FIELD           | Поле класса             |
| LOCAL_VARIABLE  | Локальная переменная    |
| METHOD          | Метод класса            |
| PACKAGE         | Описание пакета         |
| PARAMETER       | Параметр метода         |
| TYPE            | Указывается над классом |

Аннотация, использование, обработка:

```java
//Annotation with array parameter
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
public @interface ExceptionTest {
    Class<? extends Exception>[] value();
}

//Usage of the annotation
@ExceptionTest({IndexOutOfBoundsException.class, NullPointerException.class})
public void myMethod() {
}

//By reflexion you can use the annotation this way
m.

isAnnotationPresent(ExceptionTest .class);

//Or get the values this way :
Class<? extends Exception>[] excTypes = m.getAnnotation(ExceptionTest.class).value();

```

Плюсы аннотации:

- При неправильном именовании, может не пройти компилятор (`@Retention(RetentionPolicy.RUNTIME)`)
- Можно ограничить использование элемента (`@Target(ElementType.METHOD)`)
- Можно указать параметр аннотации в качестве примитивного типа, объекта или
  массива (`@ExceptionTest({IndexOutOfBoundsException.class, NullPointerException.class}`)
- Можно использовать повторяемый тип аннотации:

```java

@ExceptionTest(IndexOutOfBoundsException.class)
@ExceptionTest(NullPointerException.class)
public static void doublyBad() {
}
```

## 6.7 Последовательно используйте аннотацию Override (Item 40)

Следует использовать аннотацию `@Override` для каждого объявления метода, которое, как вы полагаете, перекрывает
объявление суперкласса.

Если объявить её у метода, который неправильно переопределяет метод суперкласса, то компилятор вызовет ошибку.

```java

@Override //Compilation error
public boolean equals(Bigram b) {
    return b.first == first && b.second == second;
}

@Override //  The correct sign to override the super method
public boolean equals(Object b) {
}

```

## 6.8 Используйте интерфейсы-маркеры для определения типов (Item 41)

Интерфейс-маркер представляет собой интерфейс, не содержащий методов для реализации, а лишь маркирует класс, реализующий
интерфейс, как имеющий определенные свойства. Например, `Serializable`.

Преимущества интерфейс-маркеров над
аннотациями-маркерами ([Item 30](#66-предпочитайте-аннотации-схемам-именования-item-39)):

- Интерфейсы-маркеры определяют тип, который реализуется экземплярами маркированного класса; аннотации-маркеры этим
  свойством не обладают
- Интерфейсы-маркеры могут быть более точно нацелены

Преимущество аннотации-маркерами перед интерфейсами-маркерами: они являются частью более мощной системы аннотаций.

Необходимо использовать аннотации, если маркер применяется к любому элементу программы, кроме класса или интерфейса.
Если маркер применяется только к классам или интерфейсам, то нужно задать себе вопрос: "Может ограничиться одним или
несколькими методами, которые принимают только объекты, типы которых это интерфейсы-маркеры?". Если это так, то
предпочесть интерфейс-маркер.

Если вы пишете тип аннотации-маркера, целью которого является `ElementType.TYPE`, то потратьте время на выяснение,
действительно ли это должен быть тип аннотации или же более целесообразным будет применение интерфейса-маркера.

# 7 Лямбда-выражения и Stream API

## 7.1 Предпочитайте лямбда-выражения анонимным классам (Item 42)

Функциональный интерфейс (до Java 8 "функциональный тип") - это интерфейс, который имеет один метод для реализации. При
этом нет ограничения на другие методы.
Функциональный объект - это экземпляр класса, реализующий функциональный интерфейс.

До Java 8 основным способом создания функционального объекта был анонимный
класс ([Item 24](#410-предпочитайте-вложенный-статический-класс-вложенному-внутреннему-классу-item-24)). В Java 8 язык
формализовал концепцию интерфейсов с единственным абстрактным методом как отдельную, заслуживающую особой обработки. И
язык позволяет создавать их экземпляры с помощью лямбда-выражений. Лямбда-выражения функционально равны анонимным
классам.

```java
public class SortFourWays {
    public static void main(String[] args) {

// Anonymous class instance as a function object - obsolete!
        Collections.sort(
                words,
                new Comparator<>() {
                    @Override
                    public int compare(String s1, String s2) {
                        return Integer.compare(s1.length(), s2.length());
                    }
                });

// Lambda expression as function object (replaces anonymous class)
        Collections.sort(
                words,
                Comparator < String > comparator = (s1, s2) -> Integer.compare(s1.length(), s2.length()));
    }
}

```

Типы для лямбда-выражения самого объекта и его параметров можно не записывать, компилятор определяет типы из контекста.
Опустите типы всех параметров лямбда-выражения, если только они не делают вашу программу яснее.

Реализацию компаратора можно и упростить, использовав метод построения компаратора + ссылку на
метод ([Item 43](#73-предпочитайте-использовать-стандартные-функциональные-интерфейсы-item-44)):
`Collections.sort(words, comparingInt(String::length)))`.

Добавление лямбда-выражения в язык делает практичным использование функциональных объектов.

В примере из [Item 34](#61-используйте-перечисление-вместо-констант-int-item-34) поведение связанное с константами,
можно реализовать с помощью лямбда-выражения. Использовав стандартный функциональный интерфейс `DoubleBinaryOperator`(
[Item 44](#73-предпочитайте-использовать-стандартные-функциональные-интерфейсы-item-44)) и реализовать метод `apply`,
который делегирует вызов метода функционального объекта `applyAsDouble`:

```java
public enum Operation {
    PLUS("+", (x, y) -> x + y),
    MINUS("-", (x, y) -> x - y),
    TIMES("*", (x, y) -> x * y),
    DIVIDE("/", (x, y) -> x / y);

private final String symbol;
    private final DoubleBinaryOperator op;

Operation(String symbol, DoubleBinaryOperator op) {
        this.symbol = symbol;
        this.op = op;
    }

@Override
    public String toString() {
        return symbol;
    }

public double apply(double x, double y) {
        return op.applyAsDouble(x, y);
    }

```

Если вычисление требует оставлять пояснений в виде комментариев или превышает несколько строк, не используйте для
него лямбда-выражение.

Для лямбда-выражения идеально одна строка кода, а три это разумный максимум. Если лямбда-выражения длинное или сложное
для чтения, либо упростите его, либо сделайте рефакторинг и замените его.

Что можно сделать с анонимными классами, и нельзя - с лямбда-выражениями.

- Если нужно создать экземпляр абстрактного класса, то это можно сделать с помощью анонимного класса, но не
  лямбда-выражения.
- Анонимные классы можно использовать для создания экземпляров интерфейсов с несколькими абстрактными методами.
- Лямбда-выражения не может получить ссылку на себя. В лямбда-выражение ключевое слово `this` ссылается на объект в
  котором содержится лямбда выражение. В анонимном классе ключевое слово `this` ссылается на экземпляр анонимного
  класса.

Лямбда-выражения, как и экземпляр анонимного класса нельзя надежно сериализовать и десериализовать. Как можно реже(если
вообще придется это делать) сериализуйте лямбда-выражение.

## 7.2 Предпочитайте ссылки на методы лямбда-выражениям (Item 43)

Помимо лямбда-выражения, есть более краткий способ создать функциональный интерфейс - ссылки на метод. Если у метода, на
который необходимо указать ссылку, параметры совпадают с параметрами лямбда-выражения, то можно использовать специальную
запись в виде ссылки на метод:

```java
public class Freq {
    public static void main(String[] args) {

// Lambda
        frequencyTable.merge(s, 1, (count, incr) -> count + incr);

// Lambda with Integer static method
        frequencyTable.merge(s, 1, (count, incr) -> Integer.sum(count, incr));

// Method reference
        frequencyTable.merge(s, 1, Integer::sum);
    }
}

```

Чаще ссылка на метод имеет более краткую запись, чем лямбда-выражения. Но если это не так, то лучше использовать
лямбда-выражения:

`service.execute(GoshThisClassNameIsHumongous::action);`

`service.execute(() -> action());`

Типы ссылок на методы

| **Тип ссылки**      | **Пример**               | **Эквивалетное лямбда-выражение**                         |
|---------------------|--------------------------|-----------------------------------------------------------|
| Статическая         | `Integer::parseInt`      | `str -> Integer.parseInt(str)`                            |
| Ограниченная        | `Instant.now()::isAfter` | `Instant then = Instant.now();`<br/>` t->then.isAfter(t)` |
| Неограниченная      | `String::toLowerCase`    | `str -> str.toLowerCase()`                                |
| Конструктор класса  | `TreeMap<K,V>::new`      | `() -> new TreeMap<K,V>`                                  |
| Конструктор массива | `int[]::new`             | `len -> new int[len]   `                                  |

## 7.3 Предпочитайте использовать стандартные функциональные интерфейсы (Item 44)

С появлением лямбда-выражения, значительно изменились лучше практики написания API. Например, паттерн
**Шаблонный метод**, в котором подкласс переопределяет абстрактный метод для специализации поведения суперкласса,
становиться менее привлекательным. Современная альтернатива - представить статическую фабрику или конструктор, который
принимает функциональный объект, с помощью чего будет достигнуть тот же результат.

Поскольку необходимость создания функционального объекта возрастает. Выбор правильного типа функционального параметра
требует внимания.

Пакет `java.util.function` предоставляет вам большую коллекцию стандартных функциональных интерфейсов. Если один из
стандартных функциональных интерфейсов выполняет нужную вам работу, в общем случае следует использовать именно его, а не
специализированный самописный функциональный интерфейс.

Основные функциональные интерфейсы:

| **Интерфейс**       | **Сигнатура функции** | **Пример**            |
|---------------------|-----------------------|-----------------------|
| `UnaryOperator<T>`  | `T apply(T t)`        | `String::toLowerCase` |
| `BinaryOperator<T>` | `T apply(T t1, T t2)` | `BigInteger::add`     |
| `Predicate<T>`      | `boolean test(T t)`   | `Collection::isEmpty` |
| `Function<T,R>`     | `R apply(T t)`        | `Arrays::asList`      |
| `Supplier<T>`       | `T get()`             | `Instant::now`        |
| `Consumer<T>`       | `void accept(T t)`    | `System.out::println` |

Если необходимо написать собственный функциональный интерфейс, то к разработке необходимо отнестись с
осторожностью ([Item 21](#47-проектируйте-интерфейсы-для-потомков-item-21)). Всегда аннотируйте ваши функциональные
интерфейсы с помощью аннотации `@FunctionalInterface`.

Не делайте перезагрузку метода ([Item 52](#84-перезагружайте-методы-разумно-item-52)), которые принимают разные
функциональные интерфейсы в одно и той же позиции аргумента, если это может привести к возможной неоднозначности в
команде клиента. Например, в `ExecutorService` метод `submit` может принимать `Callable<T>` или `Runnable`.

## 7.4 Разумно используйте Stream API (Item 45)

Stream API - это инструмент, который позволяет работать со структурами данных в стиле функциональных языков
программирования.

Stream API имеет два вида методов:

1. Конвейерные — возвращают другой stream, то есть работают как `builder`
2. Терминальные — возвращают другой объект, такой как коллекция, примитивы, объекты, `Optional` и т.д.

Stream API вычисляются отложено: вычисления не начинаются до тех пор, пока не будет вызвана завершающая операция, и
никогда не вычисляются элементы данных, которые не нужны для выполнения завещающей операции.

Stream API может выполнять операции как последовательно, так и параллельно, для этого нужно вызвать метод `parallel` для
любого потока в конвейере, но это уместным бывает редко.

Злоупотребление Stream API затрудняет чтение и поддержку кода.

Без Stream API:

```java
// Prints all large anagram groups in a dictionary iteratively
public class IterativeAnagrams {
    public static void main(String[] args) throws IOException {
        File dictionary = new File(args[0]);
        int minGroupSize = Integer.parseInt(args[1]);

Map<String, Set<String>> groups = new HashMap<>();
        try (Scanner s = new Scanner(dictionary)) {
            while (s.hasNext()) {
                String word = s.next();
                groups.computeIfAbsent(alphabetize(word),
                        (unused) -> new TreeSet<>()).add(word);
            }
        }

for (Set<String> group : groups.values())
            if (group.size() >= minGroupSize)
                System.out.println(group.size() + ": " + group);
    }

private static String alphabetize(String s) {
        char[] a = s.toCharArray();
        Arrays.sort(a);
        return new String(a);
    }
}

```

Злоупотребление Stream API:

```java
// Overuse of streams - don't do this!
public class StreamAnagrams {
    public static void main(String[] args) throws IOException {
        Path dictionary = Paths.get(args[0]);
        int minGroupSize = Integer.parseInt(args[1]);

try (Stream<String> words = Files.lines(dictionary)) {
            words.collect(
                            groupingBy(word -> word.chars().sorted()
                                    .collect(StringBuilder::new,
                                            (sb, c) -> sb.append((char) c),
                                            StringBuilder::append).toString()))
                    .values().stream()
                    .filter(group -> group.size() >= minGroupSize)
                    .map(group -> group.size() + ": " + group)
                    .forEach(System.out::println);
        }
    }
}
```

Корректное применение Stream API:

```java
// Tasteful use of streams enhances clarity and conciseness
public class HybridAnagrams {
    public static void main(String[] args) throws IOException {
        Path dictionary = Paths.get(args[0]);
        int minGroupSize = Integer.parseInt(args[1]);

try (Stream<String> words = Files.lines(dictionary)) {
            words.collect(groupingBy(word -> alphabetize(word)))
                    .values().stream()
                    .filter(group -> group.size() >= minGroupSize)
                    .forEach(g -> System.out.println(g.size() + ": " + g));
        }
    }

private static String alphabetize(String s) {
        char[] a = s.toCharArray();
        Arrays.sort(a);
        return new String(a);
    }
}
```

В отсутствии явного указания типов тщательное именование параметров лямбда-выражения имеет важное значение для
удобочитаемости конвейеров потоков. В примере `HybridAnagrams` параметр `g`, должен назваться `group`, но
тогда получилось длинная строка.

Применение вспомогательных методов для удобочитаемости в конвейерах потоков даже более важно, чем в итеративном коде. В
примере `HybridAnagrams` используется метод `alphabetize`.

Воздерживайтесь от использования потоков для обработки значений типа char:

`"Hello world!".chars().forEach(System.out::print); -> 721011081081113211911111410810033`

`"Hello world!".chars().forEach(x -> System.out.print((char) x)); -> Hello world!`

Выполняйте рефакторинг существующего кода для использования потоков и используйте их в новом коде только там, где это
имеет смысла.

Конвейерные методы используют в основном в качестве параметра функциональные объекты.

Есть вещи, которые можно сделать с помощью блоков кода с `for`, но не получиться сделать из функциональных объектов в
Stream API:

- Из блока кода можно прочесть или изменить любую локальную переменную в области видимости; из лямбда-выражения можно
  прочесть только финальные или фактически финальные переменные, и нельзя изменять никакие локальные переменные.
- В блоке кода можно выполнить оператор `return` для выхода из охватывающего метода, прервать или продолжить выполнение
  охватывающего цикла с помощью оператора `break` и `continuе`, или сгенерировать любое проверяемое исключение, которое
  этот метод объявил как могущее быть сгенерированным; из лямбда-выражения нельзя сделать ни одно из перечисленных
  действий.

Но что можно сделать с помощью Stream API:

- Единообразное преобразование последовательностей элементов.
- Фильтрование последовательностей элементов.
- Объединение последовательностей элементов с помощью единственной операции(например, сложение, конкатенация или
  вычисление минимума).
- Накопление последовательности элементов в коллекции, возможно, с группировкой по некоторым общим атрибутам.
- Поиск в последовательности элементов некоторого элемента, удовлетворяющего некоторым критериям поиска.

В Stream API сложно сделать одновременное обращение к элементам на разных этапах конвейера. Одним из способов обхода
этого является отображение каждого значения на объект пары, содержащий исходное и новое значения, но это решение не
является удовлетворительным, в особенности если такие объекты пар требуются для нескольких этапов конвейера. Такой код
беспорядочный и многословный. Когда это приемлемо и когда нужен доступ к значению на более ранней стадии вычислений,
лучше инвертировать использованное отображение.

`static Stream<BigInteger> primes(){return Stream.iterate(TWO,BigInteger::nextProbablePrime);}`

Есть много задач, для которых не очевидно, что следует использовать: Stream API или итерации. Все сводится к личным
предпочтениям и среде разработки.

Пример:

```java
public class Card {
    // Iterative Cartesian product computation
    private static List<Card> newDeckIterative() {
        List<Card> result = new ArrayList<>();
        for (Suit suit : Suit.values())
            for (Rank rank : Rank.values()) result.add(new Card(suit, rank));
        return result;
    }

// Stream-based Cartesian product computation
    private static List<Card> newDeckStream() {
        return Stream.of(Suit.values())
                .flatMap(suit -> Stream.of(Rank.values()).map(rank -> new Card(suit, rank)))
                .collect(toList());
    }
}

```

## 7.5 Предпочитайте в потоках функции без побочных эффектов (Item 46)

Stream API это не просто инструмент для работы со структурами данных, это целая парадигма основанная функциональном
программировании. Поэтому, чтобы получить выразительность, скорость и возможность параллельных вычислений, при работе с
потоками, нужно принять саму парадигму.

Важная часть парадигмы Stream API это приближение результата вычислений к чистой функции. Чистая функция - это функция,
результат которой зависит только от входных данных, и при этом никак не зависит от какого-либо изменяемого состояния,
так и не обновляет никакое состояние. Для этого нужно добиться, что бы функциональные объекты потоковых операций, были
без побочных эффектов. А не маскировать интервальный код, под потоковое вычисление.

*Входные данные не должны зависеть от изменяемого состояния указывает* - из лямбда-выражения можно прочесть только
финальные или фактически финальные переменные, и нельзя изменять никакие локальные
переменные ([Item 45](#74-разумно-используйте-stream-api-item-45)).

Операция `forEach` должна использоваться только для того, чтобы вывести результат потоковых вычислений, но не для
выполнения вычислений.

```java
public class Freq {
    public static void main(String[] args) {

// Uses the streams API but not the paradigm--Don't do this!
        Map<String, Long> freq = new HashMap<>();
        try (Stream<String> words = new Scanner(file).tokens()) {
            words.forEach(
                    word -> {
                        freq.merge(word.toLowerCase(), 1L, Long::sum);
                    });
        }

// Proper use of streams to initialize a frequency table
        Map<String, Long> freq;
        try (Stream<String> words = new Scanner(file).tokens()) {
            freq = words.collect(groupingBy(String::toLowerCase, counting()));
        }
    }
}

```

Для того чтобы правильно использовать потоки, нужно лучше изучить `Collectors`. Наиболее
важные: `toList`, `toSet`, `toMap`, `groupingBy` и `joing`.

## 7.6 Предпочитайте коллекции потокам в качестве возвращаемых типов (Item 47)

При написании метода, который возвращает последовательность элементов, клиенту может потребовать вернуть их как
коллекцию или вернуть их как поток.

`Сollection` или подходящий подтип в общем случае является наилучшим типом возвращаемого значения для открытого метода,
возвращающего последовательность. Поскольку `Collection` подтип `Iterable` и обеспечивает итеративный доступ, а также
имеет метод `stream` и обеспечивает также же потоковый доступ.

Если невозможно вернуть `Сollection`, то нужно вернуть `Stream` или `Iterable`, в зависимости от задачи. `Stream` не
расширяет `Iterable`, поэтому отсутствует итеративный доступ. Но можно написать свои адаптеры `Stream` - `Interable`:

```java
public class Adapters {
    // Adapter from  Stream<E> to Iterable<E>
    public static <E> Iterable<E> iterableOf(Stream<E> stream) {
        return stream::iterator;
    }

// Adapter from Iterable<E> to Stream<E>
    public static <E> Stream<E> streamOf(Iterable<E> iterable) {
        return StreamSupport.stream(iterable.spliterator(), false);
    }
}

```

## 7.7 Будьте внимательны при многопоточном использовании Stream API (Item 48)

Написание многопоточных программ на языке Java становиться все проще, но написание правильных и быстрых многопоточных
программ остается таким же сложным, как и ранее.

Что сделать конвейерные операции в Stream API многопоточными, нужно вызвать метод `parallel()`.

Многопоточные конвейерные операции вряд ли увеличат производительность, если источник получен от `Stream.iterate` или
используется промежуточная операция `limit`.

Не делайте многопоточные Stream API без надлежавшего разбора его работы.

Выигрыш в производительности от применения параллелизма оказывается наибольшим в случае обработки
экземпляров `ArraysList`, `HashMap`, `HashSet` и `ConcurrentHashMap`; массивов; диапазоны `int` и `long`. Основные
факторы:

- Эти структуры могут точно и дешево быть разделены на поддиапазоны любых желаемых размеров, что позволяет легко
  разделить работу при многопоточности
- Они обеспечивают очень хорошую локальность ссылок при последовательной обработке: ссылки последовательных элементов
  хранятся в памяти рядом одна с другой.

Если значительное количество работы выполняется в завершающей операции, то мультипольный конвейер будет иметь
ограниченную эффективность. С точки зрения многопоточности, лучшие завершающие операции это
приведения: `reduce`, `min`, `count`, `sum`. А операции, выполняемые `collect`, плохие кандидаты для многопоточности
из-за накладные расходов объединения коллекции.

Многопоточность Stream API может привести не только к низкой производительности, включая ошибки живучести, но и к
неверным результатам и непредсказуемому поведению (ошибкам безопасности).

При соответствующих обстоятельствах можно достичь ускорения, почти линейно зависящего от количества ядер процессора,
просто добавив вызов `parallel` в конвейер потока.

# 8 Методы

## 8.1 Проверяйте корректность параметров (Item 49)

При написании метода или конструктора, нужно продумать какие ограничения имеются для его параметров. Необходимо отразить
эти ограничения в документации, а также реализовать в начале работы метода явную проверку их выполнения. А отказ от
этого может привести к нарушению принципа атомарности сбоев.

В документации, исключения которые могут быть сгенерированы при неправильном параметре помечаются
дескриптором `@throws`([Item 56](#88-пишите-документирующие-комментарии-для-всех-открытых-элементов-api-item-56)).
Основные используемы для этого исключения: `IllegalArgumentException`, `IndexOutOfBoundsException`
и `NullPointerException`([Item 72](#104-предпочитайте-использовать-стандартные-исключения-item-72)).

Метод `Objects.requireNonNull`, гибкий и удобный, так что больше нет никакой причины для проверки значения `null`
вручную.

Для методов с модификатором доступа `private`, можно использовать проверку параметров с помощью `assert`:

```java
class SortUtil {
    private static void sort(long a[], int offset, int length) {

assert a != null;
        assert offset >= 0 && offset <= a.length;
        assert length >= 0 && length <= a.length - offset;
    }
}

```

Отличия `assert` от обычных проверок:

1. Если условия не выполнится, то генерируется исключение `AssertionError`.
2. Они не выполняют никаких действий и не имеют стоимости при их отключения с помощью флага командной строки `java -ea`.

Важно проверять правильность параметров, которые методом не используются, а откладываются для последующей обработки.

Можно не делать проверку, если она является дорогостоящей или непрактичной операцией, и при этом параметры неявно
проверяются непосредственно в процессе выполнения вычисления.

Если в ходе вычисления методом происходит неявная проверка корректности параметра, и если проверку не проходит, то
генерируется исключение, которое не соответствует исключению из документации. Здесь можно использовать идиому трансляции
исключения ([Item 73](#105-генерируйте-исключения-соответствующие-абстракции-item-73)).

## 8.2 При необходимости создавайте защитные копии (Item 50)

Нужно писать программы оборонительно - исходя из предположения, что клиенты вашего класса будут предпринимать все
возможное для того, чтобы разрушить его инварианты.

Некорректный неизменяемый класс:

```java
public final class Period {
    private final Date start;
    private final Date end;

/**
     * @param start the beginning of the period
     * @param end the end of the period; must not precede start
     * @throws IllegalArgumentException if start is after end
     * @throws NullPointerException if start or end is null
     */
    public Period(Date start, Date end) {
        if (start.compareTo(end) > 0) throw new IllegalArgumentException(start + " after " + end);
        this.start = start;
        this.end = end;
    }

public Date start() {
        return start;
    }

public Date end() {
        return end;
    }
}

```

Атака - изменение внутренних данных:

```java
public class Example {
  void method() {

Date start = new Date();
    Date end = new Date();
    Period p = new Period(start, end);
    end.setYear(78); // Modifies internals of p!
  }
}

```

В частном случае `Date` является устаревшим классом и не должен испльзоваться в новом коде.

В общем случае для защиты необходиом сделать защитную копию каждого изменяемого параметра конструктора:

```java
public Period(Date start, Date end) {
    this.start = new Date(start.getTime());
    this.end = new Date(end.getTime());

if (this.start.compareTo(this.end) > 0)
        throw new IllegalArgumentException(
                this.start + " after " + this.end);
}

```

Копии делаются до проверки параметров ([Item 49](#81-проверяйте-корректность-параметров-item-49)), так что проверка
корректности выполняется над копией, а не над оригиналом. Это позволяет защитить от атаки между проверкой и
использованием.

Не используйте `clone` для создания копии параметров, тип которого позволяет ненадежным сторонам создавать подклассы.

Вторая атака - изменение внутренних данных, через методы доступа:

```java
public class Example {
  void method() {
    Date start = new Date();
    Date end = new Date();
    p = new Period(start, end);

p.end().setYear(78); // Modifies internals of p!
  }
}

```

Для защиты, нужно возвращать копии изменяемых внутренних объектов:

```java
public Date start() {
    return new Date(start.getTime());
}

public Date end() {
    return new Date(end.getTime());
}

```

Лучше использовать неизменяемые объекты ([Item 17](#43-минимизируйте-изменяемость-item-17)) в качестве компонентов.

Возможно будет снижение производительности из-за создания копии. По-этому необходимо анализировать: если вы доверяете
вызываемому объекту, то можно копии не делать.

## 8.3 Тщательно проектируйте сигнатуры методов (Item 51)

Советы по проектированию API:

- Тщательно выбирайте имена методов ([Item 68](#912-придерживайтесь-общепринятых-соглашений-по-именованию-item-68))
- Не заходите слишком далеко в погоне за удобством методов. Не создавайте их слишком много
- Избегайте длинных списков параметров. 4 параметра - это максимум. Особенно вредны длинные последовательности
  параметров одного и того же типа. Что сократить есть следующие приемы: разбить метод на подметоды; создать
  вспомогательный класс, хранящий группы параметров - обычно используют вложенный статический
  класс ([Item 24](#410-предпочитайте-вложенный-статический-класс-вложенному-внутреннему-классу-item-24)); использовать
  шаблон
  строитель ([Item 2](#22-при-большом-количестве-параметров-конструктора-подумайте-о-проектном-шаблоне-строитель-item-2)).
- Предпочитайте в качестве типов параметров интерфейсы, а не
  классы ([Item 22](#48-используйте-интерфейсы-только-для-определения-типов-item-22))
- Предпочитайте двухэлементные типы перечислений для
  параметров `boolean`: `public enum TemperatureScale {CELSIUS, FARENHEIT}`

## 8.4 Перезагружайте методы разумно (Item 52)

Выбор среди перезагруженных методов является статическим, в то время как выбор переопределенного метода - динамический.

```java
public class CollectionClassifier {
    public static String classify(Set<?> s) {
        return "Set";
    }

public static String classify(List<?> lst) {
        return "List";
    }

public static String classify(Collection<?> c) {
        return "Unknown Collection";
    }

public static void main(String[] args) {
        Collection<?>[] collections = {
                new HashSet<String>(), new ArrayList<BigInteger>(), new HashMap<String, String>().values()
        };

for (Collection<?> c : collections)
            System.out.println(
                    classify(c)); // -> Unknown Collection /n Unknown Collection /n Unknown Collection
    }
}

```

В данном случае выбрался наиболее общий тип коллекции, который указан в цикле.

Выбор того, какая из перезагрузок будет вызвана, выполняется во время компиляции.

При переопределении метода, во время выполнения программы выбирается наиболее конкретный тип:

```java
    class Wine {
    String name() {
        return "wine";
    }
}

class SparklingWine extends Wine {
    @Override
    String name() {
        return "sparkling wine";
    }
}

class Champagne extends SparklingWine {
    @Override
    String name() {
        return "champagne";
    }
}

public class Overriding {
    public static void main(String[] args) {
        Wine[] wines = {
                new Wine(), new SparklingWine(), new Champagne()
        };
        for (Wine wine : wines)
            System.out.println(wine.name()); // prints: wine, sparkling wine, and champagne
    }
}    
```

Что бы в классе `CollectionClassifier` тип распознавался во время выполнения. Нужно использовать один метод и
оператор `instanceof`:

```java
public class FixedCollectionClassifier {
    public static String classify(Collection<?> c) {
        return c instanceof Set ? "Set" : c instanceof List ? "List" : "Unknown Collection";
    }
}

```

Безопасная и консервативная стратегия состоит в том, чтобы никогда не экспортировать две перегрузки с одинаковым числом
параметров. При переменном количестве аргументов - не перезагружать вовсе.

Можно всегда дать методам разные имена вместо того, чтобы их перезагружать.

Если перезагруженные методы имеют одинаковое количество параметров, но имеют "совершенно иные" типы, например `int`
и `Collection` - такое допускается.

Не перегружайте методы, принимающие различные функциональные интерфейсы с одной и той же позиции аргумента.

При эволюции классов бывает необходимость нарушить рекомендации выше. Например, в Java 5
метод `String::contentEquals(StringBuffer)` переопределяется с типом параметра `CharSequence`, который является общим
для других `String`-классов. Что бы для клиента разница в использовании не была замена, необходимо сохранить поведение и
у старого метода вызывать новый понижением типа:

```java

public boolean contentEquals(StringBuffer sb) {
    return contentEquals((CharSequence) sb);
}

```

## 8.5 Используйте методы с переменным количеством аргументов с осторожностью (Item 53)

Методы с переменным количеством аргументов, также называется методы с переменной арности, принимают нуль или более
аргументов:

```java
public class Varargs {
    // The WRONG way to use varargs to pass one or more arguments!
    static int min(int... args) {
        if (args.length == 0) throw new IllegalArgumentException("Too few arguments");
        int min = args[0];
        for (int i = 1; i < args.length; i++) if (args[i] < min) min = args[i];
        return min;
    }
}

```

Если будет вызов без аргументов, то ошибка будет во время компиляции, а не выполнения и необходимо делать доп. проверку.

Альтернатива этому - создать метод с двумя параметрами:

```java
public class Varargs {
    static int min(int firstArg, int... remainingArgs) {
        int min = firstArg;
        for (int arg : remainingArgs) if (arg < min) min = arg;
        return min;
    }
}

```

Использование параметров переменной длины могут влиять на производительность. Можно определить с каким количеством
параметров вызывается метод наиболее часто и сделать несколько перезагрузок метода с количеством аргументов от
нуля - до популярного значения. Например, как это реализовано в `List.of()`.

## 8.6 Возвращайте пустые массивы и коллекции, а не null (Item 54)

Если метод, возвращающий коллекцию, может вернуть `null` это требует от клиента добавления проверки на `null`.

Аргументы против `null` позволяет избежать расходов на размещение в памяти пустого контейнера:

- На этом уровне нет смысле беспокоится о производительности
- Можно возвращать пустой контейнер без выделения памяти. Например, `Collections.emptyList`

## 8.7 Возвращайте Optional с осторожностью (Item 55)

Если метод не сможет вернуть значение, есть следующие подходы для реализации данной ситуации:

- Вернуть `null`
- Сгенерировать исключение
- Начиная с Java 8 вернуть `Optional<T>`

Объекты `Optional` по духу аналогичны проверяемым
исключениям ([Item 70](#102-используйте-для-восстановления-проверяемые-исключения-а-для-программных-ошибок---непроверяемые-item-70)) -
заставляют клиента признать, что возвращаемого значения может и не быть, и требует дополнительного стереотипного кода
клиента. Необрабатываемые исключения и `null` позволяют игнорировать этот случай, что чревато плохими последствиями.

Никогда не возвращайте значение `null` из метода, возвращающего `Optional`: тем самым теряется сам смысл его
использования.

Типы контейнеров, включая коллекции, `Map`, `Stream`, массивы и `Optional`, не должны оборачиваться в `Optional`.

Следует объявлять метод как возвращающий `Optional<T>` если он не в состоянии возвратить результат, а клиенты должны
выполнить специальную обработку, когда результат не возвращается. Но возврат `Optional` может влиять на
производительность.

Никогда не следует возвращать `Optional` для упакованных примитивных типов, для этого следует
использовать: `OptionalInt`, `OptionalLong` и `OptionalDouble`.

Не следует использовать `Optional` как ключ, значение или элемент, коллекции или массива.

## 8.8 Пишите документирующие комментарии для всех открытых элементов API (Item 56)

Чтобы должным образом документировать свой API, следует предварять каждый экспортируемый класс, интерфейс, конструктор,
метод и объявление поля документирующим комментарием.

Если класс поддерживает сериализацию, следует также документировать его сериализированную
форму ([Item 87](#123-подумайте-о-применении-пользовательской-сериализованной-формы-item-87)).

Открытые классы не должны использовать конструкторы по-умолчанию, потому что нет никакого способа предоставить для них
документирующих комментарии.

Документирующий комментарий метода должен лаконично описывать контракт между этим методом и его клиентом:

- Контракт должен точно оговаривать, что делает данный метод, а не как он это делает
- Необходимо перечислить все предусловия и постусловия
- Обычно предусловия неявно описывается дескриптором `@throws` для непроверяемых исключений
- Предусловия могут указываться вместе с параметрами, которых они касаются, в соответствующих параметрах `@param`
- Должны быть документированы любые побочные эффекты. Побочный эффект - это наблюдаемое изменение состояние системы,
  которое является неочевидным условием для достижения постусловия.
- Каждый комментарий должен включать в себя дескрипторы: `@param`, `@return`, `@throws`.

```java
public class DocExamples<E> {

/**
     * Returns the element at the specified position in this list.
     *
     * <p>This method is <i>not</i> guaranteed to run in constant time. In some implementations it may
     * run in time proportional to the element position.
     *
     * @param index index of element to return; must be non-negative and less than the size of this
     *     list
     * @return the element at the specified position in this list
     * @throws IndexOutOfBoundsException if the index is out of range ({@code index < 0 || index >=
     *     this.size()})
     */
    E get(int index) {
        return null;
    }

// Use of @implSpec to describe self-use patterns & other visible implementation details.

/**
     * Returns true if this collection is empty.
     *
     * @implSpec This implementation returns {@code this.size() == 0}.
     * @return true if this collection is empty
     */
    public boolean isEmpty() {
        return false;
    }

// Use of the @literal tag to include HTML and javadoc metacharacters in javadoc comments.

/** A geometric series converges if {@literal |r| < 1}. */
    public void fragment() {
    }

// Controlling summary description when there is a period in the first "sentence" of doc comment.

/** A suspect, such as Colonel Mustard or {@literal Mrs. Peacock}. */
    public enum FixedSuspect {
        MISS_SCARLETT,
        PROFESSOR_PLUM,
        MRS_PEACOCK,
        MR_GREEN,
        COLONEL_MUSTARD,
        MRS_WHITE
    }

// Generating a javadoc index entry in Java 9 and later releases.

/** This method complies with the {@index IEEE 754} standard. */
    public void fragment2() {
    }

// Documenting enum constants (Page 258)

/** An instrument section of a symphony orchestra. */
    public enum OrchestraSection {
        /** Woodwinds, such as flute, clarinet, and oboe. */
        WOODWIND,

/** Brass instruments, such as french horn and trumpet. */
        BRASS,

/** Percussion instruments, such as timpani and cymbals. */
        PERCUSSION,

/** Stringed instruments, such as violin and cello. */
        STRING;
    }

// Documenting an annotation type

/**
     * Indicates that the annotated method is a test method that must throw the designated exception
     * to pass.
     */
    @Retention(RetentionPolicy.RUNTIME)
    @Target(ElementType.METHOD)
    public @interface ExceptionTest {
        /**
         * The exception that the annotated test method must throw in order to pass. (The test is
         * permitted to throw any subtype of the type described by this class object.)
         */
        Class<? extends Throwable> value();
    }
}

```

В документирующем комментарии слово `this` всегда указывает на объект, которому принадлежит вызываемый метод.

При создании класса для наследования необходимо документировать его схемы использования собственных
объектов ([Item 19](#45-проектируйте-и-документируйте-наследование-либо-запрещайте-его-item-19)), это
обычно документируется с помощью `@implSpec`.

Документирующие комментарии должны быть читаемыми как в исходном тексте, так и в сгенерированной документации.

Первым предложением комментария является краткое описание того элемента, к которому этот комментарий относится.

Никакие два члена или конструктора в одном классе или интерфейсе не должны иметь одинаковое краткое описание.

При документировании обобщенного типа или метода убедитесь, что вы документируете все параметры.

При документировании типа перечисления убедитесь, что вы документируете константы.

При документировании типа аннотации убедитесь, что вы документируете все члены.

Документирующие комментарии уровня пакета следует помещать в файл c именем `package-info.java`.

Является ли класс безопасным с точки зрения многопоточности или нет - в любом случае уровень его безопасности с точки
зрения потоков должен быть документирован ([Item 82](#115-документируйте-безопасность-с-точки-зрения-потоков-item-82)).
Если класс сериализуется, нужно документировать сериализованный
тип ([Item 87](#123-подумайте-о-применении-пользовательской-сериализованной-формы-item-87)).

# 9 Общие вопросы программирования

## 9.1 Минимизируйте область видимости локальных переменных (Item 57)

Наиболее мощный способ минимизировать область видимости локальной переменной заключается в её объявлении там, где она
впервые используются.

Почти каждое объявление локальной переменной должно содержать инициализатор.

Следует предпочитать цикл `for` циклу `while` при условии, что после завершения цикла содержимое переменной цикла не
требуется.

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

## 9.2 Предпочитайте циклы for для коллекции традиционным циклам for (Item 58)

Идиомы обхода коллекции или массива с использованием `for`:

```java
class ForIdiom {
    public static void main(String[] args) {

// Классическая идиома обхода с использованием переменной для индекса
        for (int i = 0, n = expensiveComputation(); i < n; i++) {
        }

// Идиома обхода в случае необходимости доступа к итератору
        for (Iterator<Element> i = c.iterator(); i.hasNext(); ) {
        }

// Предпочтительная идиома обхода коллекции
        for (Element e : c) {
        }
    }
}

```

Минус первых двух идиом:

- Итераторы и индексные переменные создают лишние помехи - для работы нужны только сами элементы
- Итераторы в цикле встречаются 3 раза, а индексная переменная 4 раза. Можно использовать неверную переменную
- Излишние обращают внимание на тип контейнера и создают сложности при изменении типа

Когда нельзя применить цикл по коллекциям:

- **Деструктивная фильтрация** - если нужно удалить элемент из коллекции, то нужно использовать явный итератор. Начиная
  с Java 8 можно попробовать метод метод `removeIf`
- **Преобразования** - если требует заменить элементы, то нужно использовать итератор или индекс массива
- **Параллельное итерирование** - если нужен параллельный обход нескольких коллекций, требуется явное управление
  итератором или индексной переменной

## 9.3 Изучите и используйте возможности библиотек (Item 59)

Преимущества использования библиотек:

- Вместе со стандартной библиотекой вы используете знания написавших её экспертов, а также опыт тех, кто работал с ней
  до вас
- Не нужно терять время на написание решений для разовых задач, имеющих лишь косвенное отношение к вашей работе
- Производительность имеет тенденцию со временем повышаться, причем без каких-либо усилий с вашей стороны

**Не изобретайте велосипед!**

С каждой новой версией в библиотеки включается множество новых функций, и стоит быть в курсе всех новшеств.

Каждый программист должен знать основные возможности пакетов `java.lang`, `java.util`, `java.io`, а также их
подпакетов. А также библиотеки для многопоточности `java.util.concurrent`.

## 9.4 Если вам нужны точные ответы, избегайте float и double (Item 60)

Для вычисления, требующих точного результата, в том числе и для финансовых, не используйте типы с плавающей точкой -
`float` и `double`.

Как альтернатива класс `BigDecimal`(18+ цифр): отслеживает положение десятичной точки, полный контроль над
округлением (можно выбрать режим).

Если требуется большая производительность и не пугает самостоятельное отслеживание десятичной точки, а обрабатываемые
значения не слишком велики можно использовать `int`(<=9 цифр) и `long`(<=18 цифр).

## 9.5 Предпочитайте примитивные типы упакованных примитивным типам (Item 61)

В Java переменные бывают двух типов: примитивные(`int`, `double`, `boolean` и др.) и ссылочные(`String`, `List` и др.).
Для каждого примитивного типа есть аналог ссылочного типа, например `int` - `Integer`. Данные классы называются -
упакованные примитивные типы.

Основные различия примитивных и упакованных типов:

- У примитивных типов есть только значения, а у упакованных ещё и идентичность
- Примитивные типы имеют только полнофункциональные значения, а упакованные могут иметь нефункциональные - `null`
- Примитивные типы эффективны с точки зрения потребления памяти и времени работы, чем упакованные

Применение оператора `==` к упакованным примитивным типа почти всегда ошибочно, лучше сравнивать через `equals`.

При смешивании обычных и упакованных примитивных типов в одной операции - упакованных примитивный типа автоматически
распаковывается. Если объект нулевой (`null`), то возможно сгенерируется исключение `NullPointerException`. Также из-за
распаковки, может снижаться производительность.

Когда использовать упакованные типы:

- В качестве элементов, ключей и значений коллекций
- В качестве параметров в параметризованных типах ([Item 26](#51-не-используйте-сырые-типы-item-26))
- При вызове рефлексивных методов ([Item 65](#99-предпочитайте-интерфейсы-рефлексии-item-65))

## 9.6 Избегайте применения строк там, где уместнее другой тип (Item 62)

Класс `String` предназначен для представления текста.

Когда его не следует применять:

- `String` - плохая замена другим типам значений. При парсинге лучше сразу преобразовать в нужный тип
- `String` - плохая замена для перечислений ([Item 34](#61-используйте-перечисление-вместо-констант-int-item-34))
- `String` - плохая замена для агрегатных типов. Например, `String key = className + "#" + i.next();`
- `String` - плохая замена надежным (устойчивым к подделке) ключам

## 9.7 Помните о проблемах производительности при конкатенации строк (Item 63)

Время, которое необходимо оператору конкатенации для последовательного объединения n объектов `String`, пропорционально
квадрату n. Это следует из-за неизменяемого класса ([Item 17](#43-минимизируйте-изменяемость-item-17)).

Низкая производительность при объединении большого количеств строк:

```java
class Concatenation {
    // Inappropriate use of string concatenation - Performs horribly!
    public String statement() {
        String result = "";
        for (int i = 0; i < numItems(); i++) result += lineForItem(i);
        return result;
    }
}

```

Применение `StringBuilder` для повышения производительности:

```java
class Concatenation {
    public String statement() {
        StringBuilder b = new StringBuilder(numItems() * LINE_WIDTH);
        for (int i = 0; i < numItems(); i++) b.append(lineForItem(i));
        return b.toString();
    }
}

```

## 9.8 Для ссылки на объекты используйте их интерфейсы (Item 64)

Если имеются подходящие типы интерфейсов, то параметры, возвращаемые значения, переменные и поля следует объявлять,
используя типы интерфейсов.

Плохо - испльзование классов в качестве типов:

`ArraysList<Son> subscribers = new ArraysList<>();`

Хорошо - использование интерфейсов в качестве типов:

`List<Son> subscribers=new ArraysList<>();`

Если вы выработаете привычку использовать в качестве типов интерфейсы, ваша программа будет более гибкой.

Можно изменить объект не меняя переменную:

`List<Son> subscribers=new LinkedList<>();`

Если исходная реализация интерфейса предлагала некоторую особенную функциональность, не предусмотренную общим контрактом
этого интерфейса, а код зависел от этой функциональности, крайне важно, чтобы новая реализация интерфейса обеспечивала
ту же функциональность.

Вполне допустимо ссылаться на объект с использованием класса, а не интерфейса, если подходящий интерфейс отсутствует:

- Классы значений: `String`, `BigInteger` и др.
- Классы фреймворков
- Если класс, реализующий интерфейс, предоставляет дополнительные методы, которых нет в интерфейсе

## 9.9 Предпочитайте интерфейсы рефлексии (Item 65)

Ядро средств рефлексии, `java.lang.reflect`, предоставляет программный доступ к произвольным классам.

Можно получить доступ через тип `Class` к `Constructor`, `Method` и `Field`. А также манипулировать классами/объектами.

Рефлексия позволяет одному классу использовать другой класс, даже если последний во время компиляции первого ещё не
существовал. Цена данного подхода:

- Вы теряете все преимущества проверки типов времени компиляции
- Код, необходимый для рефлексивного доступа к классам, неуклюжий и многословный
- Проблемы с производительностью

Вы можете без особых затрат воспользоваться многими преимуществами рефлексии, применяя её в очень ограниченном виде.

Во многих программах нужный класс отсутствует во время компиляции, для ссылки на него можно использовать подходящий
интерфейс или суперкласс. А экземпляры создавать рефлексивно, а затем обращаться к ним, как обычно, используя их
интерфейс или суперкласс.

```java
public class ReflectiveInstantiation {
    // Reflective instantiation with interface access
    public static void main(String[] args) {
        // Translate the class name into a Class object
        Class<? extends Set<String>> cl = null;
        try {
            cl =
                    (Class<? extends Set<String>>) // Unchecked cast!
                            Class.forName(args[0]);
        } catch (ClassNotFoundException e) {
            fatalError("Class not found.");
        }

// Get the constructor
        Constructor<? extends Set<String>> cons = null;
        try {
            cons = cl.getDeclaredConstructor();
        } catch (NoSuchMethodException e) {
            fatalError("No parameterless constructor");
        }

// Instantiate the set
        Set<String> s = null;
        try {
            s = cons.newInstance();
        } catch (IllegalAccessException e) {
            fatalError("Constructor not accessible");
        } catch (InstantiationException e) {
            fatalError("Class not instantiable.");
        } catch (InvocationTargetException e) {
            fatalError("Constructor threw " + e.getCause());
        } catch (ClassCastException e) {
            fatalError("Class doesn't implement Set");
        }

// Exercise the set
        s.addAll(Arrays.asList(args).subList(1, args.length));
        System.out.println(s);
    }

private static void fatalError(String msg) {
        System.err.println(msg);
        System.exit(1);
    }
}

```

Это технология достаточно мощная для реализации фреймворка.

Пример выше демонстрирует два недостатка рефлексии:

- Пример может генерировать шесть различных исключений во время выполнения, а без рефлексии может выявлена во время
  компиляции
- Для создания экземпляра через рефлексию требуется несколько десятков строк кода, а для использования конструктора -
  одна

## 9.10 Пользуйтесь машинно-зависимыми методами осторожно (Item 66)

Интерфейс `Java Native Interface` позволяет вызывать машинно-зависимые методы, которые написанные на
машинно-зависимых языках программирования, таких как `C` или `C++`.

Такие методы имели три основных предназначения:

- Обеспечивали доступ к средствам платформы, например реестр `Windows`
- Обеспечивали доступ к существующим библиотекам с машинным кодом
- Эти методы использовались при написании критических в плане производительности фрагментов приложения

Но по мере развития платформы `Java` их использование редко необходимо. Использовать машинно-зависимые методы для
повышения производительности редко целесообразно.

Применение машинно-зависимых методов имеют недостатки:

- Приложения становятся восприимчивы к ошибкам, связанные с памятью
- Для новой платформы машинно-зависимых программный код необходимо компилировать заново
- Труднее отлаживать
- При отсутствии опыта применение этих методов может привести к снижению производительности. Сборщик мусора не может
  отслеживать применение таких методов
- Требуют дополнительного "склеивающего кода", который сложно писать и читать

## 9.11 Оптимизируйте осторожно (Item 67)

Не жертвуйте надежными архитектурными принципами во имя производительности. Старайтесь писать хорошие, а не быстрые
программы. Если программа работает недостаточно быстро, правильная архитектура позволит её оптимизировать.

Старайтесь избегать проектных решений, ограничивающих производительность. Рассматривайте влияние на производительность
проектных решений, на которых основан ваш API. Не следует изменять и искажать API достижения высокой производительности.

Измеряйте производительность до и после каждой попытки оптимизации. Если после измерения программа медленная - найдите
источник проблемы с помощью профайлера.

Для оптимизации изучите выбор алгоритма: никакая низкоуровневая оптимизация не сможет компенсировать плохой выбор
алгоритма.

## 9.12 Придерживайтесь общепринятых соглашений по именованию (Item 68)

Группы соглашения по наименованию:

**Типографические**

| Тип                       | Пример                                        |
|---------------------------|-----------------------------------------------|
| Пакет                     | com.google.inject, org.joda.time.format       |
| Класс/Интерфейс           | Timer, FutureTask, LinkedHashMap, HttpServlet |
| Метод/поле                | remove, ensureCapacity, getCrc                |
| Константы                 | MIN_VALUE, NEGATIVE_INFINITY                  |
| Локальные переменные      | i, xref, houseNumber                          |
| Формальные параметры типа | T, E, K, V, X, T1, T2                         |

**Грамматические**

| Тип                                                             | Соглашение                                                                                                      | Пример                                                    |
|-----------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------|
| Классы инстанцируемые, Enum, Интерфейсы                         | Существительные в единственным числе или именные группы                                                         | Thread, PriorityQueue, ChessPiece, Collection, Comparator |
| Классы утильные                                                 | Существительные во множественном числе                                                                          | Collectors, Collections                                   |
| Интерфейсы                                                      | Прилагательные с окончанием -able или -ible                                                                     | Runnable, Iterable,  Accessible                           |
| Аннотации                                                       | Так как у аннотаций много вариантов использования - можно разные части речи                                     | BindingAnnotation, Inject, ImplementedBy, Singleton       |
| Методы выполняющие действия                                     | Глаголы или глагольные конструкции                                                                              | append, drawImage                                         |
| Методы возвращающие булевые значения                            | Сначала слово is(реже has), потом существительное, именная группа, любое слово или фраза в роле прилагательного | isDigit, isProbablePrime, isEmpty, isEnabled, hasSiblings |
| Методы возвращающие не булевые значения                         | Существительное, именная группа, глагольная группа начинающаяся с get                                           | size, hashCode, getTime                                   |
| Методы конвертации типов                                        | Именуются toType                                                                                                | toString, toArray                                         |
| Методы возвращающие представление типа, отличный от вызываемого | asType                                                                                                          | asList                                                    |
| Методы возвращающие примитивные типы с тем же значением         | typeValue                                                                                                       | intValue                                                  |
| Статистические фабрики                                          | см. [Item 1](#21-рассмотрите-применение-статических-фабричных-методов-вместо-конструкторов-item-1)              | valueOf, of, getInstance, newInstance, getType, newType   |
| Поля булевые                                                    | Также как методы, но без is или has                                                                             | initialized, composite                                    |
| Поля не булевые                                                 | Существительные или именные группы                                                                              | height, digits, bodyStyle                                 |
| Локальные переменные                                            | Аналогично для полей, но соблюдение менее обязательно                                                           |                                                           |

# 10 Исключения

## 10.1 Используйте исключения только в исключительных ситуациях (Item 69)

Исключения, как и подразумевает их название, должны применяться лишь для исключительных ситуаций; для обычного
управления потоком выполнения их не следует использовать никогда.

Хорошо спроектированный API не должен заставлять своих клиентов использовать исключения для обычного управления потоком
выполнения.

## 10.2 Используйте для восстановления проверяемые исключения, а для программных ошибок - непроверяемые (Item 70)

* Проверяемые исключения `Exception` - ситуации, которые разработчик никак не может предотвратить, например, не
  получилось закрыть файловый дескриптор или отослать письмо, и исключение является одним из вариантов нормальной работы
  кода.
* Непроверяемые исключения
    * Ошибки время выполнения `RuntimeException` - ситуации, когда основной причиной ошибки является сам разработчик,
      например, происходит обращение к `null` ссылке, деление на ноль, выход за границы массива и т.д. При этом
      исключение не является одним из вариантов нормальной работы кода.
    * Системные ошибки `Error` - критические ошибки, аварийные ситуации, после которых мы с трудом или вообще не в
      состоянии продолжить работу. Например, закончилась память, переполнился стек вызовов и т.д. Ошибки зарезервированы
      при использовании `JVM`, чтобы указывать на дефицит ресурсов, поэтому лучше не создавать новых классов `Error`.

Если возникают сомнения, является ли исключение рабочим моментом приложения или программной ошибкой - генерируйте
непроверяемые исключения.

Не создавайте классы исключений, которые не являются ни `Exception`, ни `RuntimeException`.

Для классов исключения, можно создавать вспомогательные методы, которые снабжает исключение дополнительной информацией о
ситуации.

## 10.3 Избегайте ненужных проверяемых исключений (Item 71)

Проверяемые исключения заставляют программиста работать с возникшей проблемой.

Проверяемые исключения следует использовать при условии:

- Предотвратить возникновение исключительной ситуации невозможно даже при надлежащем применении API
- Программист, пользующийся данным API, может предпринять некоторые полезные действия, столкнувшись с этим исключением

Если хоть одно из этих условий не выполняется, следует использовать непроверяемые исключения.

Если метод генерирует единственное проверяемое исключение, то можно рассмотреть возможность использовать `Optional` в
качестве возвращаемого типа, вместо исключения, если при этом будет достаточно передаваемой информации.

## 10.4 Предпочитайте использовать стандартные исключения (Item 72)

Часто используемые стандартные исключения:

| Exception                       | Причина                                               |
|---------------------------------|-------------------------------------------------------|
| IllegalArgumentException        | Неверное ненулевое значение                           |
| IllegalStateException           | Неверное состояние объекта для вызова метода          |
| NullPointerException            | Неразрешённое нулевое значение параметра              |
| IndexOutOfBoundsException       | Индексный параметр за границей допустимого диапазона  |
| ConcurrentModificationException | Обнаружено запрещенное параллельное изменение объекта |
| UnsupportedOperationException   | Объект не поддерживает метод                          |

Не используйте `Exception`, `RuntimeException`, `Throwable` и `Error` непосредственно.

## 10.5 Генерируйте исключения, соответствующие абстракции (Item 73)

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

```java
class ExceptionTranslation {
    public static void main(String[] args) {
        // Exception Translation
        try {
            // Use lower-level abstraction to do our bidding
        } catch (LowerLevelException e) {
            throw new HigherLevelException("...");
        }
    }
}

```

Трансляция цепочкой исключений - исключение нижнего уровня передается исключению верхнего уровня, которое, в свою
очередь, предоставляет метод доступа(метод `getCause` в `Throwable`), позволяющий получить исключение нижнего уровня.

```java
class ExceptionСhaining {
    public static void main(String[] args) {
        // Exception Translation
        try {
            // Use lower-level abstraction to do our bidding
        } catch (LowerLevelException cause) {
            throw new HigherLevelException(cause);
        }
    }
}

```

Трансляция исключения лучше бессмысленной передачи исключений нижнего уровня, злоупотреблять ею не следует. Где это
возможно, наилучший способ обработки исключений нижнего уровня - полное исключение их возможности путем обеспечения
гарантированной успешности вызова метода нижнего уроня.

## 10.6 Документировать все исключения, которые может генерировать метод (Item 74)

Всегда объявляйте проверяемые исключения индивидуально, и точно документируйте условия, при которых каждое из них
генерируется.

Важна документация непроверяемых исключений, которые могут быть сгенерированы методами интерфейсов, такая документация
является частью общего контракта.

Используйте дескриптор `Javadoc` `@throws` для описания каждого исключения, которое может быть сгенерировано методом, но
не используйте ключевое слово `throws` для непроверяемых исключений.

Если одно и то же исключение генерируется несколькими методами класса по одной и то же причине, его можно
документировать в общей документации всего класса.

## 10.7 Включайте в сообщения информацию о сбое (Item 75)

Для сохранения информации о сбое, строковое представление исключения должно содержать значения всех параметров и полей,
приведших к генерации исключения.

Не включайте пароли, ключи шифрования и прочую подобную информацию в детальные сообщения о сбоях.

Чтобы гарантировать, что строковое представление будет содержать нужную информацию, в конструктор помещать информацию о
сбое, а не строковое представление. Само сообщение будет генерироваться автоматически.

```java
public class IndexOutOfBoundsException extends RuntimeException {

public IndexOutOfBoundsException(int lowerBound, int upperBound, int index) {
        // Generate a detail message that captures the failure
        super(
                String.format(
                        "Lower bound: %d, Upper bound: %d, Index: %d", lowerBound, upperBound, index));

// Save failure information for programmatic access
        this.lowerBound = lowerBound;
        this.upperBound = upperBound;
        this.index = index;
    }
}

```

## 10.8 Добивайтесь атомарности сбоев (Item 76)

Объект атомарный по отношению к сбою - при вызове метода, завершившимся сбоем, должен оставлять проверяемый объект в том
же состоянии, в каком тот был перед вызовом.

Подходы этого добиться:

- Разработка неизменяемых объектов ([Item 17](#43-минимизируйте-изменяемость-item-17))
- Упорядочение вычислений, чтобы все части кода, способные повлечь сбой, предшествовали первой модификации объекта
- Выполнение операций над временной копией объекта и замене содержимого объекта содержимым копии по завершении операции
- Использование кода восстановления

Атомарность не всегда желательна, для некоторых операций она существенно увеличивает стоимость или сложность вычисления.

## 10.9 Не игнорируйте исключения (Item 77)

Когда разработчик API объявляют, что некоторый метод может генерировать исключение, они пытаются этим что-то вам
сказать. Не игнорируйте это!

Пустой блок `catch` лишает исключение смысла.

Но бывают ситуации, когда игнорирование целесообразно. Тогда блок `catch` должен содержать комментарий, поясняющий,
почему такое решение приемлемо, а переменная исключения должна иметь имя `ignored`:

```java
class ExceptionIgnore {
    void ignore() {

try {
        } catch (TimeoutException | ExecutionException ignored) {
            // Use default: minimal coloring is desirable, not required
        }
    }
}

```

# 11 Многопоточное программирование

## 11.1 Синхронизируйте доступ к совместно используемым изменяемым данным (Item 78)

Ключевое слово `synchronized` гарантирует, что в любой момент времени метод или блок будет выполняться только
одним потоком.

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

Java гарантирует, что чтение и запись примитивной переменной атомарна, кроме `long` и `double`. Но атомарные данные тоже
необходимо синхронизировать, так как нет гарантии, что значение, записанное одним потоком, будет видимо другим.

Синхронизация необходима как для взаимоисключения потоков, так и для надежного взаимодействия между ними.

```java
// Broken! - How long would you expect this program to run?
public class StopThread {
    private static boolean stopRequested;

public static void main(String[] args) {
        Thread backgroundThread =
                new Thread(
                        () -> {
                            int i = 0;
                            while (!stopRequested) i++;
                        });
        backgroundThread.start();
        TimeUnit.SECONDS.sleep(1);
        stopRequested = true;
    }
}

```

Код выше выполняется бесконечно, в отсвутсвии синхронизации нет гаранитированного времени, когда поток, подлежащий
остановке, увидит измененное в основном потоке значения `stopRequested`. При отсутсвии сихнонизации JVM может
преобразовать код: `while(!stopRequested) i++` -> `if(!stopRequested) while(true) i++`. Это называется поднятием.

Решение:

```java
// Properly synchronized cooperative thread termination
public class StopThread {
    private static boolean stopRequested;

private static synchronized void requestStop() {
        stopRequested = true;
    }

private static synchronized boolean stopRequested() {
        return stopRequested;
    }

public static void main(String[] args) {
        Thread backgroundThread =
                new Thread(
                        () -> {
                            int i = 0;
                            while (!stopRequested) i++;
                        });
        backgroundThread.start();

TimeUnit.SECONDS.sleep(1);
        requestStop();
    }
}

```

Работа синхронизации не гарантируется, если не синхронизированы обе операции - и чтения, и записи.

Менее многословная альтернатива с более высокой производительности с использованием ключевого слова `volatile`.

```java
public class StopThread {
    private static volatile boolean stopRequested;

TimeUnit.SECONDS.sleep(1);
        stopRequested = true;
    }
}

```

Модификатор `volatile` не обеспечивает взаимоисключения, он гарантирует, что любой поток, который читает поле, увидит
последнее записанное в поле значение.

Использовать поле `volatile` нужно с осторожностью, в случае не атомарной операции над объектом:

```java
public class SerialNumber {
    private static volatile int nextSerialNumber = 0;

public static int generateSerialNumber() {
        return nextSerialNumber++;
    }
}

```

Оператор инкремента(`++`) не атомарный. И разные потоки могут получать значение переменной, до того как выполнится
инкрементация. Что бы метод обрабатывался корректно нужно использовать ключивое слово `synchronized`.

Лучше последовать совету из [Item 59](#93-изучите-и-используйте-возможности-библиотек-item-59) и использовать
библиотеку `java.util.concurrent.atomic` и класс `AtromicLong`, он представляет примитив безопасный с точки зрения
многопоточности:

```java
public class SerialNumber {
    private static final AtomicLong nextSerialNum = new AtomicLong();

public static long generateSerialNumber() {
        return nextSerialNum.getAndIncrement();
    }
}

```

Фактически неизменяемые(effectively immutable) объекты - у которого часть данных может изменить один поток, и
синхронизировать только изменяемые данные. При этом доступ к другим незаменяемым данным можно выполнять без
синхронизации.

Наилучший способ избежать вышеописанных проблем - не использовать совместно изменяемые данные. Ограничивайте изменяемые
данные одним потоком.

## 11.2 Избегайте излишней синхронизации (Item 79)

Для исключения проблем с живучестью и безопасностью никогда не передавайте управление клиенту из синхронизированного
метода или блока. То есть из синхронизированного области не следует вызывать методы, которые предназначены для
переопределения, или метод, предоставленный клиентом в форме функционального
объекта ([Item 42](#71-предпочитайте-лямбда-выражения-анонимным-классам-item-42)) - чужие методы.

```java
public class ObservableSet<E> extends ForwardingSet<E> {

private final List<SetObserver<E>> observers = new ArrayList<>();

private void notifyElementAdded(E element) {
        // Broken - invokes alien method from synchronized block!
        synchronized (observers) {
            for (SetObserver<E> observer : observers) observer.added(this, element);
        }
    }

@Override
    public boolean add(E element) {
        boolean added = super.add(element);
        if (added) notifyElementAdded(element);
        return added;
    }
}

```

Что бы избежать связанных с этим проблем, можно переместить вызов чужого метода за пределы синхронизированных блоков и
получать "снимок" объекта с которым можно безопасно работать.

```java
public class ObservableSet<E> extends ForwardingSet<E> {

// Alien method moved outside of synchronized block - open calls
    private void notifyElementAdded(E element) {
        List<SetObserver<E>> snapshot = null;
        synchronized (observers) {
            snapshot = new ArrayList<>(observers);
        }
        for (SetObserver<E> observer : snapshot) observer.added(this, element);
    }
}

```

Либо использовать библиотеку предоставляющая параллельную
коллекцию ([Item 81](#114-предпочитайте-утилиты-параллельности-методам-wait-и-notify-item-81)) `CopyOnWriteArraysList`.
В которой все модифицирующие операции реализуется с помощью создания копии базового массива. Внутренний массив никогда
не изменяется и итерации не требуют блокировки и выполняются очень быстро.

```java
public class ObservableSet<E> extends ForwardingSet<E> {

// Thread-safe observable set with CopyOnWriteArrayList
    private final List<SetObserver<E>> observers = new CopyOnWriteArrayList<>();

private void notifyElementAdded(E element) {
        for (SetObserver<E> observer : observers) observer.added(this, element);
    }
}

```

Нужно выполнять как можно меньше действий внутри синхронизированной области.

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

Для синхронизации объекта изменяемого класса есть две стратегии:

1. Разрешить клиенту выполнять внешнюю синхронизацию
2. Сделать синхронизацию внутреннюю, то есть сделать объект
   потокобезопасным ([Item 82](#115-документируйте-безопасность-с-точки-зрения-потоков-item-82))

Если вы сомневаетесь, не синхронизируйте свой класс, но обязательно документируйте, что он не потокобезопасный.

Если несколько потоков могут вызвать метод, который изменяет статическое поле, нужно синхронизировать доступ к полю
внутренне.

## 11.3 Предпочитайте исполнителей, задания и потоки данных потокам исполнения (Item 80)

Для создания очереди задач, которые выполняются в многопоточном режиме, лучше использовать `Executor Framework` из
библиотеки `java.util.concurrent`

Например, фабрика с единственным потоком:

`ExecutorService executor = Executors.newSingleThreadExecutor();`

Передать очереди задания для выполнения:

`executor.execute(runnable);`

Корректно завершить работу очереди:

`executor.shutdown();`

Возможности `Executor Framework`:

- подождать, пока не завершиться определенная задача: `get`
- подождать, пока одна или все задачи не завершаться: `invokeAny` и `invokeAll`
- подождать, пока служба не завершиться: `awaitTermination`
- поочередно выводить результаты выполненных задач по мере завершения: `ExecutorCompletionService`
- обрабатывать запросы с разным количеством потоков: разные фабрики класса `java.util.concurrent.Executor`
- управлять почти всеми аспектами работы пула потоков: `ThreadPoolExecutor`

Для небольших программ или мало нагруженных серверов можно выбрать фабрику `Executors.newCachedThreadPool`. Для
высоконагруженных `Executors.newFixedThreadPool`.

Следует воздержаться от написания собственных рабочих очередей и от непосредственной работы с потоками. Если работать
непосредственно с классом `Thread`, он служит в качестве единицы работы, так и в качестве механизма её выполнения.

В `Executor Framework` единица работы и выполнения разделены.
Абстракция единицы работы является - задание. Их виды:

- `Runnable`
- `Callable`(так же как и `Runnable`, но ещё возвращает результат)

Общий механизм выполнения называется службой исполнителя(executors service).

## 11.4 Предпочитайте утилиты параллельности методам wait и notify (Item 81)

Начиная c Java 5 появились высокоуровневые утилиты параллельности, которые делают то, что раньше приходилось писать
вручную поверх `wait` и `notify`.

Высокоуровневые утилиты из `java.util.concurrent`:

- `Executor Framework` ([Item 80](#113-предпочитайте-исполнителей-задания-и-потоки-данных-потокам-исполнения-item-80))
- Потокобезопасные коллекции
- Синхронизаторы

Потокобезопасные коллекции, являются потокобезопасной реализацией стандартных интерфейсов коллекций: `List`, `Queue`,
и `Map`. Они сами внутренне управляют своей синхронизацией. Исключить многопоточную работу из потокобезопасной коллекции
невозможно, её общая блокировка будет только тормозить выполнение программы.

Не используйте синхронизируемые коллекции. Например, используйте `ConcurrentHashMap`
вместо `Collections.synchronizedMap`.

Синхронизаторы предоставляют собой объекты, которые дают возможность потокам ожидать один другого, позволяя тем самым
координировать их деятельность(`CountDownLatch,` `Semaphore`, `Phaser`), вместо операций `wait` и `notify`.

Если используется устарелый код с `wait` и `notify`. То для `wait` необходимо использовать стандартную идиому:

```java
class IdiomWait {
    void idiom() {
        // The standard idiom for using the wait method
        synchronized (obj) {
            while (<condition does not hold>)
            obj.wait(); // (Releases lock, and reacquires on wakeup)
        }
        // Perform action appropriate to condition
    }
}

```

Всегда используйте идиому цикла ожидания для вызова метода `wait`; никогда не вызывайте его вне цикла.

Причины просыпания потока при невыполненном условии:

- Другой поток может получить блокировку и изменить защищенное состояние, когда поток вызвал `notify`.
- Другой поток может вызвать `notify` случайно или злоумышленно при несоблюдении условия.
- Уведомляющий поток может быть слишком "щедрым" на пробуждение ожидающих потоков.
- Ожидающий поток может проснуться при отсутствии уведомления(ложное пробуждения)

В основном следует использовать метод `notifyAll`, `notify` можно использовать в качестве оптимизации, если достаточно
разбудить один поток из множества.

Причина использовать `wait` и `notify` в новом коде встречается редко(если встречается вообще).

## 11.5 Документируйте безопасность с точки зрения потоков (Item 82)

Для каждого класса необходимо четко документировать свойства безопасности с точки зрения многопоточности с помощью
аккуратно составленного текстового описания или аннотации многопоточной безопасности.

Наличие в объявлении метода модификатора `synchronized` - это деталь реализации, а не часть API. Наличие модификатора не
является надежной гарантией того, что метод безопасен с точки зрения потоков.

Чтобы класс можно было безопасно использовать в многопоточной среде, в документации к нему должно быть четко указано,
какой уровень безопасности он поддерживает.

Уровни многопоточной безопасности:

- **Неизменяемый** (immutable). Для констант внешней синхронизации не требуется. `String`, `Long` и `BigInteger` и др.
- **Безусловная безопасность с точки зрения потоков** (unconditionally thread-safe). Могут быть изменяемы, но при этом
  потокобезопасны. `AtomicLong`, `ConcurrentHashMap` и др.
- **Условная безопасность с точки зрения потоков** (conditionally thread-safe). Потокобезопасный при определенных
  условиях, описанных в документации. Коллекции `Collections.synchronized`.
- **Небезопасны с точки зрения потоков** (not thread-safe). Для многопоточного использования клиенту нужно окружить
  каждый вызов метода внешней синхронизацией. `ArraysList`, `HashMap` и др.
- **Несовместимы с многопоточностью** (thread-hostile). Такие классы не пишут целенаправленно; обычно это результат
  неспособности понять параллелизм.

Эти категории примерно соответствуют аннотациям потокобезопасности: `@Immutable`, `@ThreadSafe` и `@NotThreadSafe`.

При документировании класса с условной безопасностью, необходимо указать, какие последовательности вызовов требуют
внешней синхронизации и какую блокировку необходимо захватывать для выполнения этих последовательностей.

Для класса с безусловной безопасностью, нужно рассмотреть использования закрытого объекта блокировки (идиома закрытого
объекта блокировки) вместо синхронизированных методов. Это защитит от вмешательства синхронизацию со стороны клиентов
и подклассов, и обеспечит гибкость в применении более сложных подходов к управлению параллельностью в последующих
версиях.

```java
class LockObjectIdiom {
    // Private lock object idiom - thwarts denial-of-service attack
    private final Object lock = new Object();

public void foo() {
        synchronized (lock) {
            // ...
        }
    }
}

```

## 11.6 Аккуратно применяйте отложенную инициализацию (Item 83)

Отложенная (ленивая) инициализация представляет собой задержку инициализации поля до тех пор, пока его значение не
потребуется для вычислений. Если полю обращается только часть экземпляров и инициализация поля требует существенных
затрат, то, возможно, стоит использовать отложенную инициализацию.

В большинстве случаев обычная инициализация предпочтительнее отложенной:

```java
// Normal initialization of an instance field
private final FieldType field = computeFieldValue();
```

При отложенной инициализации, чтобы избежать зацикленность инициализации, необходимо использовать синхронизированный
метод доступа:

```java
public class Initialization {
    // Lazy initialization of instance field - synchronized accessor
    private FieldType field;

private synchronized FieldType getField() {
        if (field == null) field = computeFieldValue();
        return field;
    }
}

```

Отложенная инициализация статического поля с использованием идиомы класса отложенной инициализации (для повышения
производительности):

```java
public class Initialization {
    // Lazy initialization holder class idiom for static fields
    private static class FieldHolder {
        static final FieldType field = computeFieldValue();
    }

static FieldType getField() {
        return FieldHolder.field;
    }
}

```

Отложенная инициализация поля экземпляра для повышения производительности с идиомой двойной проверки:

```java
public class Initialization {
    // Double-check idiom for lazy initialization of instance fields
    private volatile FieldType field;

FieldType getField() {
        FieldType result = field;
        if (result == null) { // First check (no locking)
            synchronized (this) {
                result = field;
                if (result == null) // Second check (with locking)
                    field = result = computeFieldValue();
            }
        }
        return result;
    }
}

```

Локальная переменная `result` нужна для гарантии однократного чтения `field` в распространенном случае, когда она уже
инициализирована. Хотя в ней нет острой необходимости, она может улучшить производительность(примерно на 25%) и повысить
элегантность с точки зрения стандартов низкоуровневого параллельного программирования.

Если поле экземпляра допускает повторную инициализацию, можно использовать идиому однократной проверки:

```java
public class Initialization {
    // Single-check idiom - can cause repeated initialization!
    private volatile FieldType field;

private FieldType getField() {
        FieldType result = field;
        if (result == null) field = result = computeFieldValue();
        return result;
    }
}
```

## 11.7 Избегайте зависимости от планировщика потоков (Item 84)

Любая программа, корректность или производительность которой зависит от планировщика потоков, скорее всего, переносимой
не будет.

Лучший способ написать надежную, с малым временем отклика, переносимую многопоточную программу состоит в том, чтобы в
любой момент времени среднее количество работающих потоков не было значительно больше количества процессоров. Потоки
не должны запускаться, если они не выполняют полезную работу.

Потоки не должны быть в активном ожидании с регулярной проверкой состояния совместно используемого объекта в ожидании
изменения этого состояния.

Приоритеты работы потоков находится среди наименее переносимых возможностей Java.

# 12 Сериализация

## 12.1 Предпочитайте альтернативы сериализации Java (Item 85)

Фундаментальная проблема сериалзиации состоит в том, что область, в которой она может быть атакована (проблемы с
безопасностью) слишком велика для защиты и постоянно растет: графы объектов десериализуются с помощью вызовов метода
`readObject` над `ObjectInputStream`. Сериализация опасна, и её следует избегать.

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

Лучше использовать механизмы преобразования между объектами и последовательность байтов, у которых могут быть
достоинства, такие как эти:

- кроссплатформенность
- высокая производительность
- больше инструментов
- опыт большого сообщества программистов
- гораздо проще сериализации

Например, JSON и Protocol Buffers.

Если нельзя избежать сериализации, то никогда не десериализуйте непроверенные данные. Для этого можно использовать
фильтр десериализуемых объектов `java.io.ObjectInputFilter` с черными и белыми списками классов.

## 12.2 Реализуйте интерфейс Serializable крайне осторожно (Item 86)

Что бы сделать класс сериализуемым достаточно добавить в объявлении метода `implements Serializable`. Но сериализация
требует от программиста гораздо больше усилий и требует учитывать следующие особенности:

- Уменьшает возможности изменения реализации класса в последующих версиях
- Повышается вероятность появления ошибок и брешей в системе
  безопасности ([Item 85](#121-предпочитайте-альтернативы-сериализации-java-item-85))
- Выпуск новой версии класса сопряжен с большой работой по тестированию

Классы, предназначенные для
наследования ([Item 19](#45-проектируйте-и-документируйте-наследование-либо-запрещайте-его-item-19)), редко должны
реализовывать `Serializable`, а интерфейсы - редко его расширять.

Внутренние классы ([Item 24](#410-предпочитайте-вложенный-статический-класс-вложенному-внутреннему-классу-item-24)) не
должны реализовывать `Serializable`.

## 12.3 Подумайте о применении пользовательской сериализованной формы (Item 87)

Нельзя принимать сериализованную форму, предлагаемую по умолчанию, не обдумав как следует, насколько она устраивает.
Можно принимать сериалзиованную форму по умолчанию только тогда, когда она практически идентична той кодировке, которую
вы бы выбрали, если бы проектировали серилизованную форму сами. Чаще всего бывает, когда физическое представление
объекта идентично его логическому содержанию (например, класс имени или точки в системе координат).

Даже если вы решите, что сериалзиованная форма по умолчанию для вас пригодна, имейте в виду, что зачастую для
обеспечения инвариантов и безопасности требуется предоставление
метода `readObject` ([Item 88](#124-создавайте-защищенные-методы-readobject-item-88)).

Сериализованная форма по умолчанию:

```java
public final class StringList implements Serializable {

private transient int size = 0;
    private transient Entry head = null;

private static class Entry implements Serializable {
        String data;
        Entry next;
        Entry previous;
    }
}

```

Применение сериализованной формы по умолчанию, когда физическое представление объекта существенно отличается от
содержащихся в нем логических данных, имеет следующие недостатки:

- Она навсегда связывает внешний API класса с его текущим внутренним представлением
- Она может потреблять слишком много памяти
- Она может требовать слишком много времени
- Она может вызвать переполнение стека

Правильная сериалзиованная форма:

```java
public final class StringList implements Serializable {

private transient int size = 0;
    private transient Entry head = null;

// No longer Serializable!
    private static class Entry {
        String data;
        Entry next;
        Entry previous;
    }

/**
     * Serialize this {@code StringList} instance.
     *
     * @serialData The size of the list (the number of strings it contains) is emitted ({@code int}),
     *     followed by all of its elements (each a {@code String}), in the proper sequence.
     */
    private void writeObject(ObjectOutputStream s) throws IOException {
        s.defaultWriteObject();
        s.writeInt(size);

// Write out all elements in the proper order.
        for (Entry e = head; e != null; e = e.next) s.writeObject(e.data);
    }

private void readObject(ObjectInputStream s) throws IOException, ClassNotFoundException {
        s.defaultReadObject();
        int numElements = s.readInt();

// Read in all elements and insert them in list
        for (int i = 0; i < numElements; i++) add((String) s.readObject());
    }
}

```

Изменения:

- Все поля сериализованного класса помечены как `transient`. Каждое поле, которое не требуется помещать в
  сериализованную форму, следует пометить этим модификатором. Прежде чем решить сделать какое-то поле не
  являющимся `transient`, убедитесь в том, что его значение является частью логического состояния объекта
- Методы `defaultWriteObject` и `defaultReadObject` согласно спецификации вызываются в любом случае. Это необходимо для
  прямой и обратной совместимости в следующих версиях класса
- Методы `writeObject` и `readObject` с модификатором доступа `private` документированы, они определяют сериализованную
  форму и являются открытым API
- Производительность исправленной сериализованной формы быстрее в 2 раза и в 2 раза меньше занимает памяти

Нужно использовать для сериализации объекта ту же синхронизацию, что и для любого иного метода чтения всего состояния
объекта.

```java
class Sync {
    // writeObject for synchronized class with default serialized form
    private synchronized void writeObject(ObjectOutputStream s) throws IOException {
        s.defaultWriteObject();
    }
}

```

Независимо от того, какую сериализованную форму вы выберете, в каждом сериализуемом классе, который вы пишите, явным
образом объявляйте идентификатор версии сериализации. Это исключает его из числа потенциальных источников
несовместимости.

`private static final long serialVersionUID = randomLongValue;`

Не изменяйте идентификатор версии, если только вы не хотите нарушить совместимость со всеми существующими
сериализованными экземпляра класса.

## 12.4 Создавайте защищенные методы readObject (Item 88)

Метод `readObject` фактически является открытым конструктором, который приминает в качестве входных параметров поток
байтов.

Рекомендации по написанию `readObject` (включают рекомендации по созданию открытого конструктора):

- Для классов с полями, в которых хранятся ссылки на объекты и должны оставаться закрытыми, выполняйте защитное
  копирование каждого объекта в таком поле. Изменяемые компоненты неизменяемых классов также попадают в эту
  категорию
- Выполняйте проверку инвариантов и в случае ошибки генерируйте исключение `InvalidObjectException`. Проверки должны
  производиться после защитного копирования ([Item 50](#82-при-необходимости-создавайте-защитные-копии-item-50))
- Если после десериализации необходимо проверить весь граф объектов, используйте интерфейс `ObjectInputValidation`
- Ни прямо, ни косвенно не вызывайте перекрываемые методы
  класса ([Item 19](#45-проектируйте-и-документируйте-наследование-либо-запрещайте-его-item-19))

```java
class Period {
    // readObject method with defensive copying and validity checking
    private void readObject(ObjectInputStream s) throws IOException, ClassNotFoundException {
        s.defaultReadObject();

// Defensively copy our mutable components
        start = new Date(start.getTime());
        end = new Date(end.getTime());

// Check that our invariants are satisfied
        if (start.compareTo(end) > 0) throw new InvalidObjectException(start + " after " + end);
    }
}

```

Альтернатива `readObject` - проектный шаблон прокси
сериализации ([Item 90](#126-подумайте-о-применении-прокси-агента-сериализации-вместо-сериализованных-экземпляров-item-90)).

## 12.5 Для управления экземпляром предпочитайте типы перечислений методу readResolve (Item 89)

Чтобы обеспечить управление экземплярами, необходимо использовать `enum` для сериализуемого класса. Например
для синглтон ([Item 3](#23-получайте-синглтон-с-помощью-закрытого-конструктора-или-типа-перечисления-item-3)). Класс
перестает быть синглтоном, если в его объявление добавить слова `implements Serializable`.

Если применение `enum` невозможно, например, сериализуемый класс с управляемыми экземплярами, которые в момент
компиляции неизвестны. Метод `readResolve` позволяет заменить один экземпляр другим, созданным с помощью
метода `readObject`. С помощью этого метода можно управлять экземплярами класса. Если полагаетесь на метод `readResolve`
для управления экземпляром, все поля со ссылками на объект должны быть объявлены как `transient`.

Доступность метода `readResolve` имеет важное значение:

* `readResolve` в `final` классе должен быть `private`
* `readResolve` в не `final` классе
    * `private` - его действия не будут распросторонятья на подклассы
    * по-умолчанию - распространяется на подклассы в пакете
    * `protected` и `public` - распространяется на все подклассы, если подклассы не переопределяют этот метод, то
      десериализация подкласса создаст экземпляр суперкласса, который может вызвать `ClassCastException`

## 12.6 Подумайте о применении прокси-агента сериализации вместо сериализованных экземпляров (Item 90)

Если требует написать класс, который поддерживает механизм сериализации с помощью пользовательской сериализованной
формы. Рассмотрите применение шаблона прокси сериализации:

```java
// Immutable class that uses defensive copying
public final class Period implements Serializable {
    private final Date start;
    private final Date end;

/**
     * @param start the beginning of the period
     * @param end the end of the period; must not precede start
     * @throws IllegalArgumentException if start is after end
     * @throws NullPointerException if start or end is null
     */
    public Period(Date start, Date end) {
        this.start = new Date(start.getTime());
        this.end = new Date(end.getTime());
        if (this.start.compareTo(this.end) > 0)
            throw new IllegalArgumentException(start + " after " + end);
    }

public Date start() {
        return new Date(start.getTime());
    }

public Date end() {
        return new Date(end.getTime());
    }

public String toString() {
        return start + " - " + end;
    }

// Serialization proxy for Period class
    private static class SerializationProxy implements Serializable {
        private final Date start;
        private final Date end;

SerializationProxy(Period p) {
            this.start = p.start;
            this.end = p.end;
        }

private static final long serialVersionUID =
                234098243823485285L; // Any number will do (Item 87)

private Object readResolve() {
            return new Period(start, end);
        }
    }

// writeReplace method for the serialization proxy pattern
    private Object writeReplace() {
        return new SerializationProxy(this);
    }

// readObject method for the serialization proxy pattern
    private void readObject(ObjectInputStream stream) throws InvalidObjectException {
        throw new InvalidObjectException("Proxy required");
    }

}

```

Для этого необходимо добавить класс прокси сериализации внешнего класса:

- Должен быть закрытым `private`
- Описывать точно логическое состояние внешнего класса
- Иметь одним конструктором с типом параметром внешнего класса и копировать данные из него
- Должен помечен как `Serializable`
- Во внешнем классе должен быть метод `writeReplace` для сериализации прокси в который транслирует данные внешнего
  класса
- Во внешнем классе должен быть метод `readObject` который генерирует исключение при использовании. Для защиты от
  инвариантов
- Иметь метод `readResolve` для десерилизации через прокси, который транслирует уже в конечный экземпляр внешнего
  класса

Плюсы данного подхода в отличие от защитного
копирования ([Item 88](#124-создавайте-защищенные-методы-readobject-item-88)):

- Можно сделать поля `private` и сделать класс неизменяемым ([Item 17](#43-минимизируйте-изменяемость-item-17))
- Не нужно думать, какие поля могут быть дискредитированны при атаках
- Не нужно выполнять явную проверку корректности

Минусы данного подхода:

- Нельзя создавать дочерние
  классы ([Item 19](#45-проектируйте-и-документируйте-наследование-либо-запрещайте-его-item-19))
- Не совместим с классами, графы объектов которых содержат цикличность

effective-java

effective-java 최신버젼 다운로드

오늘의 추천 프로젝트

Was this content helpful?

Recent Feedback

effective-java

effective-java 최신버젼 다운로드

오늘의 추천 프로젝트

Was this content helpful?

Recent Feedback

Download README