Serializable을 구현할지는 신중히 결정하라.

클래스를 직렬화하려면 Serializable 를 impliments만 하면 되기 때문에 간단하고 신경쓸 부분이 없다고 생각하겠지만, 실제로는 훨씬 더 복잡하다. 직렬화를 지원하는것은 간단할지 몰라도 아주 값비싼 일이다.

Serializable을 구현하면 릴리즈한 뒤에는 수정하기 어렵다.

• 클래스가 직렬화를 구현하면 직렬화된 바이트 스트림 인코딩(직렬화 형태)도 하나의 공개 API가 된다. 그래서 이 클래스가 널리 퍼진다면 그 직렬화 형태도 영원히 지원을 해야한다.
• 커스텀 직렬화 형태를 설계하지 않고 자바의 기본 방식을 사용하면 직렬화 형태는 최소 적용 당시 클래스의 내부 구현 방식에 영원히 묶이게 된다. 즉 기본 직렬화 형태에서는 클래스의 private과 package-private 인스턴스 필드들 마저 API로 공개되는 꼴이 된다. 즉 캡슐화가 깨지게된다.
  • 필드로의 접근을 최대한 막아 정보은닉을 하라는 아이템(15)가 무력화되는 꼴이됨
• 뒤늦게 클래스 내부 구현을 손보면 원래의 직렬화 형태와 또 달라지게 된다. 한쪽은 구버전 인스턴스를 직렬화하고 다른 쪽은 신버전 클래스로 역직렬화를 한다면 실패한다.

<aside> 🔥 직렬화를 구현하고자 한다면 감당할 수 있을 만큼 고품질의 직렬화 형태로 설계해야한다. 고생이 그만큼 따르고 개발비용이 발생하지만 보상을 보장한다.

</aside>

직렬화가 클래스 개선을 방해하는 예시

스트림 고유 식별자 즉 직렬 버전 UID(Serial Version ID)

• 모든 직렬화된 클래스는 SerialVersionUID라는 이름의 static final long 필드의 식별 번호를 부여받는다.
  • 이 번호를 명시하지 않으면 시스템이 런타임에 암호해시 함수(SHA-1)를 적용하여 자동으로 클래스 안에 생성해 집어넣게된다.
    • 이 값을 생성하는 데는 클래스 이름, 구현한 인터페이스, 컴파일러가 자동으로 생성하여 넣는 것을 포함하며 대부분의 클래스 맴버가 대상이된다.
  • 나중에 편의 메서드를 추가하는 식으로 이들 중 하나라도 수정된다면 SerialVersionID도 변한다. 즉 자동 생성되는 값에 의존하면 쉽게 호환성이 깨져버려 런타임에 InvalidClassException이 발생한다. 따라서 직접 넣는것이 좋다.

버그와 보안 구멍이 생길 위험이 높아진다.

• 객체는 생성자를 사용해 만드는게 기본이다. 즉 직렬화는 언어의 기본 매커니즘을 우회하는 객체 생성 기법이다.
• 역직렬화는 일반 생성자의 문제가 그대로 적용되는 “숨은 생성자”이다.
  • 이 생성자는 전면에 드러나지 않아 생성자에서 구축한 불변식을 모두 보장해야 하고 생성 도중 공격자가 객체 내부를 들여다 볼 수 없도록 해야한다.
• 기본 역직렬화를 사용하면 불변식 깨짐과 허가되지 않은 접근에 쉽게 노출된다는 의미이다.

클래스의 신버전을 릴리즈 할 때 테스트할 것이 늘어난다.

• 직렬화 기능 클래스가 수정되면 신버전 인스턴스를 직렬화한 후 구버전으로 역직렬화 할 수 있는지, 그리고 그 반대도 가능한지 테스트가 필요하다.
  • 즉 테스트해야 할 양이 직렬화 가능 클래스의 수와 릴리즈 횟수에 비례해 증가하게 된다.