Когда мы должны внедрять интерфейс Serializable?

public class Contact implements Serializable {
    private String name;
    private String email;

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public String getEmail() {
        return email;
    }

    public void setEmail(String email) {
        this.email = email;
    }
}

Когда следует реализовать интерфейс Serializable?
Зачем мы это делаем?
Предоставляет ли он какие-либо преимущества или безопасность?

Ответ 1

От чего эта "сериализация" вообще вещь? :

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

Как и в Transporter на Star Trek, все сводится к тому, чтобы взять что-то сложное и превратить его в плоскую последовательность из 1 и 0, затем взять эту последовательность из 1 и 0 (возможно, в другом месте, возможно, в другое время) и восстановить исходное сложное ". что-то."

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

Ответ 2

Serializable интерфейс Serializable когда вы хотите иметь возможность преобразовать экземпляр класса в серию байтов или когда вы думаете, что объект Serializable может ссылаться на экземпляр вашего класса.
Serializable классы полезны, когда вы хотите сохранить их экземпляры или отправить их по проводам.
Экземпляры Serializable классов могут быть легко переданы. Однако сериализация имеет некоторые последствия для безопасности. Читайте Джошуа Блоха Эффективная Java.

Ответ 3

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

Нет никакой причины использовать сериализацию Java в любой новой системе, которую вы пишете

По словам главного архитектора Oracle Марка Рейнхольда, устранение существующего механизма сериализации Java является долгосрочной целью.

Почему Java-сериализация имеет недостатки

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

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

Что делать вместо

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