객체를 만들어야 할 때와 만들지 말아야 할 떄를 구분하는 법, 올바른 객체 생성 방법과 불필요한 생성을 피하는 방법, 제때 파괴됨을 보장하고 파괴 전에 수행해야 할 정리 작업을 관리하는 요렁
item 1. 생성자 대신 정적 팩터리 메서드를 고려하라.
정적 팩터리 메서드와 public 생성자는 각자의 쓰임새가 있으니 상대적인 장단점을 이해하고 사용하는 것이 좋다.
그렇다고 하더라도 정적 팩터리를 사용하는 게 유리한 경우가 더 많으므로 무작정 public 생성자를 제공하던 습관이 있다면 고치자.
👍
장점 1.
생성자의 시그니처가 중복되는 경우 팩터리 메서드를 통해 표현이 가능하다.
팩터리 메서드를 통해 객체의 특징을 이름으로 더 자세하게 표현(반환될 객체의 특성을 쉽게 묘사) 가능하다.
public class Order {
private boolean prime;
private boolean urgent;
private Product product;
/* 생성자의 시그니처가 중복되는 경우 */
public Order(Product product, boolean prime) {
this.product = product;
this.prime = prime;
}
// 'Order(Product, boolean)' is already defined in 'Order'
public Order(Product product, boolean urgent) {
this.product = product;
this.urgent = urgent;
}
}
...
public class Order {
private boolean prime;
private boolean urgent;
private Product product;
/* 팩터리 메서드로 더 자세한 표현(객체의 특징) 가능 */
public static Order primeOrder(Product product) {
Order order = new Order();
order.prime = true;
order.product = product;
return order;
}
public static Order urgentOrder(Product product) {
Order order = new Order();
order.urgent = true;
order.product = product;
return order;
}
}
장점 2.
호출될 때마다 인스턴트를 새로 생성하지 않아도 된다.
불필요한 객체 생성을 피하여 성능을 올려줄 수 있음
인스턴스 통제 클래스(instance-controlled)
java.lang.Boolean.valueOf()
public static Boolean valueOf(boolean b) {
return b ? Boolean.TRUE : Boolean.FALSE;
}
public class Settings {
private boolean useAutoSteering;
private boolean useABS;
private Difficulty difficulty;
private Settings() {}
private static final Settings SETTINGS = new Settings();
/* 객체 생성을 자신이 컨트롤 */
public static Settings getInstance() {
return SETTINGS;
}
}
...
Settings settings1 = Settings.getInstance();
Settings settings2 = Settings.getInstance();
장점 3.
반환 타입의 하위 타입 객체를 반환할 수 있는 능력이 있다.
반환할 객체의 클래스를 자유롭게 선택할 수 있는 유연성 보유
인터페이스 기반 프레임워크를 만드는 핵심 기술
장점 4.
입력 매개변수에 따라 매번 다른 클래스의 객체를 반환할 수 있다.
클라이언트는 팩터리가 건네주는 객체가 어느 클래스의 인스턴스인지 알 수도 없고 알 필요도 없다.
java.util.EnumSet.noneOf()
public interface HelloService {
String hello();
/**
* 장점 3.
*
* @return HelloService interface
* 리턴 타입은 인터페이스지만 실제 리턴 인스턴스는 인터페이스의 구현체.
* 또는
* 리턴 타입은 클래스지만 실제 리턴 인스턴스는 하위 클래스.
*/
static HelloService of(String lang) {
/**
* 장점 4.
*
* 매개변수에 따라 각기 다른 인스턴스 제공
*/
if (lang.equals("ko")) {
return new KoreanHelloService();
} else {
return new EnglishHelloService();
}
}
}
...
// 인테스이스 기반 프레임워크를 사용하도록 강제하고, 구현체는 숨길 수 있음
HelloService ko = HelloServiceFactory.of("ko");
빌더는 점층적 생성자보다 클라이언트 코드를 읽고 쓰기가 훨씬 간결하고, 자바빈즈보다 훨씬 안전하다.
📖
정적 팩터리와 생성자에 선택적 매개변수가 많을 때 고려할 수 있는 방안
점층적 생성자 패턴 또는 생성자 체이닝
매개변수가 늘어나면 클라이언트 코드를 작성하거나 읽기 어려움
자바빈즈 패턴
완전한 객체를 만들려면 (setter)메서드를 여러번 호출 필요
객체의 일관성이 무너질 수 있음
클래스를 불변으로 만들 수 없음
.
빌더 패턴
new NutritionFacts.Builder(240, 8)
.calories(100)
.sodium(35)
.carbohydrate(27)
.build();
점층적 생성자보다 클라이언트 코드를 읽고 쓰기가 훨씬 간결
필수 필드의 값은 강제하고, 옵셔널한 값은 선택적으로 세팅할 수 있으므로 자바빈즈보다 훨씬 안전
플루언트 API 또는 메서드 체이닝 적용
각 계층의 클래스에 관련 빌더를 멤버로 정의
계층 구조에서 self() 메소드를 통해 형변환을 줄이고, 하위 빌더에 메서드를 추가할 수 있음
클라이언트는 필요한 객체를 직접 만드는 대신, 필수 매개변수만으로 생성자를 호출해 빌더 객체를 얻는다.
그 후 빌더 객체가 제공하는 일종의 세터 메서드들로 원하는 선택 매개변수들을 설정
빌더 패턴의 단점도 존재
빌더 생성 비용이 크지는 않지만 성능에 민감한 상황에서는 문제가 될 수 있음
점층적 생성자 패턴보다는 코드가 장황해서 매개변수 4개 이상은 되어야 값어치를 함
.
@Builder
장점.
애노테이션 하나로 간결하게 빌더 패턴을 구현
target.classes.. 에서 생성된 Builder 클래스 확인 가능
단점.
빌더뿐만 아니라 모든 매개변수를 파라미터로 받는 생성자 자동 생성
필수값 지정 불가(필수 값을 생성자에 넣어주고 싶을 경우 어려움)
@Builder
// 모든 매개변수를 파라미터로 받는 생성자를 외부에서 호출하지 못 하도록 AccessLevel 설정
@AllArgsConstructor(access = AccessLevel.PRIVATE)
public class NutritionFacts {
private final int servingSize;
private final int servings;
private final int calories;
//..
}
...
new NutritionFacts.NutritionFactsBuilder()
.servingSize(10)
.servings(10)
.build();
item 3. private 생성자나 열거 타입으로 싱글턴임을 보증하라.
만들려는 싱글턴이 Enum 이외의 클래스를 상속하지 않는다면, "원소가 하나인 열거 타입을 선언" 방식을 선택해 보자.
📖
싱클턴을 만드는 세 가지 방법
.
private 생성자 + public static final 필드 방식의 싱글턴
public class Elvis {
public static final Elvis INSTANCE = new Elvis();
private Elvis() { }
public void leaveTheBuilding() { ... }
public void sing() { ... }
}
...
Elvis elvis = Elvis.INSTANCE;
elvis.leaveTheBuilding();
장점.
public, protected 생성자가 없으므로 클래스 초기화 시 만들어진 인스턴스가 전체 시스템에서 하나뿐임을 보장
간결하고 해당 클래스가 싱글턴인 것이 API(javadocs)에 명백히 드러남
final 이므로 다른 객체 참조 불가
단점.
(인터페이스가 없다면) 싱글톤을 사용하는 클라이언트가 테스트하기 어려움
인터페이스를 생성해서 Mock 객체로 테스트 가능
리플렉션으로 private 생성자 호출 가능
생성자 두 번째 호출 시 인스턴스 생성 막는 방법 필요
// 선언 되어 있는 기본 생성자에 접근(접근 지시자에 상관 없이 접근 가능)
Constructor<Elvis> defaultConstructor = Elvis.class.getDeclaredConstructor();
defaultConstructor.setAccessible(true);
Elvis elvis1 = defaultConstructor.newInstance();
Elvis elvis2 = defaultConstructor.newInstance();
...
// 생성자 두 번째 호출 시 인스턴스 생성 막는 방법 필요
private static boolean created;
private Elvis() {
if (created) {
throw new UnsupportedOperationException("can't be created by constructor.");
}
created = true;
}
역직렬화 시 새로운 인스턴스가 생성될 수 있음
역직렬화 시 새로운 인스턴스가아닌 기존 인스턴스 리턴하도록 재정의
// 직렬화
try (ObjectOutput out = new ObjectOutputStream(new FileOutputStream("elvis.obj"))) {
out.writeObject(Elvis.INSTANCE);
} catch (IOException e) {
e.printStackTrace();
}
// 역직렬화
try (ObjectInput in = new ObjectInputStream(new FileInputStream("elvis.obj"))) {
Elvis elvis3 = (Elvis) in.readObject();
System.out.println(elvis3 == Elvis.INSTANCE);
} catch (IOException | ClassNotFoundException e) {
e.printStackTrace();
}
...
public class Elvis implements IElvis, Serializable {
//...
// 역직렬화 시 새로운 인스턴스가아닌 기존 인스턴스 리턴하도록 재정의
// 진짜 Elvis를 반환하고, 가짜 Elvis는 가비지 컬렉터에
private Object readResolve() {
return INSTANCE;
}
}
.
private 생성자 + 정적 팩터리 방식의 싱글턴
public class Elvis {
private static final Elvis INSTANCE = new Elvis();
private Elvis() { }
public static Elvis getInstance() { return INSTANCE; }
public void leaveTheBuilding() { ... }
}
..
Elvis elvis = Elvis.getInstance();
elvis.leaveTheBuilding();
장점
API 변경 없이 싱글턴이 아니도록 변경 가능
클라이언트 코드는 유지하면서 내부 코드 변경 가능
정적 팩터리를 제네릭 싱글턴 팩터리로 만들 수 있음
클라이언트가 원하는 타입을 사용할 수 있도록 지원
public class MetaElvis<T> {
private static final MetaElvis<Object> INSTANCE = new MetaElvis<>();
private MetaElvis() { }
@SuppressWarnings("unchecked")
public static <E> MetaElvis<E> getInstance() { return (MetaElvis<E>) INSTANCE; }
public void say(T t) { ... }
public void leaveTheBuilding() { ... }
public static void main(String[] args) {
MetaElvis<String> elvis1 = MetaElvis.getInstance();
MetaElvis<Integer> elvis2 = MetaElvis.getInstance();
elvis1.say("hello");
elvis2.say(100);
}
}
정적 팩터리의 메서드 참조를 공급자(Supplier<>)로 사용 가능
public class Concert {
public void start(Supplier<Singer> singerSupplier) {
Singer singer = singerSupplier.get();
singer.sing();
}
public static void main(String[] args) {
Concert concert = new Concert();
concert.start(Elvis::getInstance);
}
}
단점
private 생성자 + public static final 필드 방식의 싱글턴과 동일한 단점
.
원소가 하나인 열거 타입을 선언
public enum Elvis {
INSTANCE;
public void leaveTheBuilding() { ... }
}
..
Elvis elvis = Elvis.INSTANCE;
elvis.leaveTheBuilding();
가장 간결한 방법이고, 직렬화와 리플렉션에도 안전
아주 복잡한 직렬화 상황이나 리플렉션 공격에서도 제 2의 인스턴스가 생기는 일을 완벽하게 방어
enum 은 리플렉션 내부 코드에서 생성자를 가져올 수 없도록 설정
new 키워드로 enum 을 생성할 수 없는 특성을 반영
대부분 상황에서 원소가 하나뿐인 열거 타입이 싱글턴을 만드는 가장 좋은 방법
단, 만들려는 싱글턴이 Enum 이외의 클래스를 상속해야 한다면 이 방법은 사용 불가
item 4. 인스턴스화를 막으려거든 private 생성자를 사용하라.
public class UtilityClass {
/**
* 이 클래스는 인스턴스를 만들 수 없습니다.
* 기본 생성자가 만들어지는 것을 방지(인스턴스화 방지로 상속 불가능)
*/
private UtilityClass() {
throw new AssertionError();
}
// ...
}
추상(abstract) 클래스로 만드는 것으로는 인스턴스화를 막을 수 없다
기본 생성자가 자동으로 생성
상속받은 자식 클래스의 인스턴스 생성 시 상위 클래스의 생성자를 자동으로 호출하는 자바 특성
컴파일러가 기본 생성자를 만드는 경우는 오직 명시된 생성자가 없을 때뿐이니 private 생성자를 추가하면 클래스의 인스턴스화를 막을 수 있다.
생성자에 주석으로 인스턴스화 불가한 이유를 설명하는 것이 좋다
상속을 방지할 때도 같은 방법을 사용할 수 있다
ex. 인스턴스를 만들 수 없는 유틸리스 클래스
정적(static) 메서드만 담은 유틸리티 클래스는 인스턴스로 만들어 쓰려고 설계한 클래스가 아님
item 5. 자원을 직접 명시하지 말고 의존 객체 주입을 사용하라.
클래스가 내부적으로 하나 이상의 자원에 의존하고, 그 자원이 클래스 동작에 영향을 준다면 싱글턴과 정적 유틸리티 클래스는 사용하지 않는 것이 좋다.
이 자원들을 클래스가 직접 만들게 해서도 안 된다.
대신 필요한 자원을(혹은 그 자원을 만들어주는 팩터리를) 생성자에(혹은 정적 팩터리나 빌더에) 넘겨주자.
의존 객체 주입이라 하는 이 기법은 클래스와의 유연성, 재사용성, 테스트 용이성을 기막히게 개선해준다.
📖
// 자원을 직접 명시하지 말고
private static final Dictionary dictionary = new Dictionary();
...
// 의존 객체 주입 사용
public class SpellChecker {
// Dictionary interface 를 주입받아서 코드의 재사용성을 높일 수 있음
private final Dictionary dictionary;
// 생성자에 필요한 자원을 넘겨준다.
public SpellChecker(Dictionary dictionary) {
this.dictionary = Object.requireNonNull(dictionary);
}
public boolean isValid(String word) { ... }
public List<String> suggestions(String typo) { ... }
}
사용하는 자원에 따라 동작이 달라지는 클래스에는 정적 유틸리티 클래스나 싱글턴 방식이 비적합
대신 클래스가 여러 자원 인스턴스를 지원해야 하며, 클라이언트가 원하는 자원을 사용해야 한다.
의존 객체 주입 패턴: 인스턴스를 생성할 때 생성자에 필요한 자원을 넘겨주는 방식
변형 방식으로 생성자에 자원 팩터리를 넘겨줄 수 있음
의존 객체 주입 통해 클래스의 유연성, 재사용성, 테스트 용이성 개선 가능
의존 객체 주입 프레임워크(Dagger, Guice, Spring)를 사용하면 큰 프로젝트에서 코드가 어지러워지는 단점 개선 가능
item 6. 불필요한 객체 생성을 피하라.
문자열
/**
* 불필요한 객체 생성으로 인한 메모리 낭비 개선
*/
String hello = "hello"; // JVM은 내부적으로 문자열을 pool에 캐싱
String hello2 = new String("hello"); // 강제로 새로운 문자열 생성
new String("str")을 사용하지 않고, 문자열 리터럴("str)을 재사용하는 것을 권장
문자열 리터럴은 사실상 동일한 객체라서 매번 새로 만들 필요가 없음
똑같은 기능의 객체를 매번 생성하기보다 객체 하나를 재사용하는 편이 나을 때가 많음
생성자 대신 정적 팩터리 메서드를 제공하는 불변 클래스에서는 정적 팩터리 메서드를 사용해 불필요한 객체 생성을 피할 수 있음
생성자는 호출할 때마다 새로운 객체를 만들지만, 팩터리 메서드는 그렇지 않다.
ex. Boolean.valueOf(String)
정규식 Pattern
/**
* 값비싼 객체를 재사용해 성능을 개선
*/
public class RomanNumerals {
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();
}
}
생성 비용(CPU 리소스)이 비싼 객체라서 반복해서 생성하기 보다, 캐싱하여 재사용하는 것을 권장
동일한 패턴이 여러번 사용된다면 필드로 선언해서 사용 권장
오토박싱(Auto Boxing)
/**
* 불필요한 객체 생성으로 인한 메모리 낭비 개선
*/
private static long sum() {
Long sum = 0L; // Long으로 선언해서 불필요한 인스턴스가 약 2^31개나 생성
for (long i = 0; i <= Integer.MAX_VALUE; i++)
sum += i;
return sum;
}
기본 타입(int)을 그에 상응하는 박싱된 기본 타입(Integer)으로 상호 변환해주는 기술
기본 타입과 박싱된 기본 타입을 섞어서 사용하면 변환하는 과정에서 불필요한 객체가 생성될 수 있음
박싱된 기본 타입보다는 기본 타입을 사용하고, 의도치 않은 오토박싱이 숨어들지 않도록 주의하자
item 7. 다 쓴 객체 참조를 해제하라.
메모리 누수는 겉으로 잘 드러나지 않아 시스템에 수년간 잠복하는 사례도 있다.
이런 누수는 철저한 코드 리뷰나 힙 프로파일러 같은 디버깅 도구를 동원해야만 발견되기도 한다.
그래서 이런 종류의 문제는 예방법을 익혀두는 것이 매우 중요하다.
📖
CG(가비지 컬렉션) 언어에서는 메모리 누수를 찾기가 아주 까다로움
메모리 누수로 단 몇 개의 객체가 매우 많은 객체를 회수되지 못하게 할 수 있고, 잠재적으로 성능에 악영향을 줄 수 있음
어떤 객체에 대한 레퍼런스가 남아있다면 해당 객체는 가비지 컬렉션의 대상이 되지 않음
해법은 해당 참조를 다 썻을 때 참조 해제(null 처리)하기
참조 해제의 가장 좋은 방법은 그 참조를 담은 변수를 유효 범위 밖으로 밀어내는 것
자기 메모리를 직접 관리하는 클래스(Stack, Cache, Listener/Callback)라면 항시 메모리 누수에 주의
.
참조 해제 방법
(1) 해당 참조를 다 사용했을 경우 null 처리
public Object pop() {
if (size == 0) {
throw new EmptyStackException();
}
Object result = elements[--size];
elements[size] = null; // 다 쓴 참조 해제
return result;
}
(2) WeakHashMap 자료구조
약한 참조로 저장(WeakHashMap애 Key로 저장) 시 가비지 컬렉터가 즉시 수거
public class PostRepository {
private Map<CacheKey, Post> cache;
public PostRepository() {
this.cache = new WeakHashMap<>();
}
public Post getPostById(CacheKey key) {
if (cache.containsKey(key)) {
return cache.get(key);
} else {
// DB, REST API를 통한 조회
Post post = new Post();
cache.put(key, post);
return post;
}
}
//...
}
...
PostRepository postRepository = new PostRepository();
CacheKey key1 = new CacheKey(1);
postRepository.getPostById(key1);
assertFalse(postRepository.getCache().isEmpty());
key1 = null;
// WeakHashMap Key 는 GC가 즉시 수거
System.out.println("run gc");
System.gc();
System.out.println("wait");
Thread.sleep(3000L);
assertTrue(postRepository.getCache().isEmpty());
(3) Background Threads & LRU Cache
LRU(Least Recently Used) cache
가장 오랫동안 사용되지 않은 캐시 제거
ScheduledExecutorService executor = Executors.newScheduledThreadPool(1);
PostRepository postRepository = new PostRepository();
CacheKey key1 = new CacheKey(1);
postRepository.getPostById(key1);
// 백그라운드 스레드에서 가장 오랫동안 사용되지 않은 캐시 제거
Runnable removeOldCache = () -> {
System.out.println("running removeOldCache task");
Map<CacheKey, Post> cache = postRepository.getCache();
Set<CacheKey> cacheKeys = cache.keySet();
Optional<CacheKey> key = cacheKeys.stream().min(Comparator.comparing(CacheKey::getCreated));
key.ifPresent((k) -> {
System.out.println("removing " + k);
cache.remove(k);
});
};
// 처음에 1초 있다가 3초마다 러너 실행
executor.scheduleAtFixedRate(removeOldCache, 1, 3, TimeUnit.SECONDS);
// 20초동안 애플리케이션을 돌리는 동안 별도의 스레드기 수행
Thread.sleep(20000L);
executor.shutdown();
item 8. finalizer와 cleaner 사용을 피하라.
cleaner(java8 까지는 finalizer)는 안전망 역할이나 중요하지 않은 네이티브 자원 회수용으로만 사용하자.
물론 이런 경우라도 불확실성과 성능 저하에 주의해야 한다.
📖
자바는 두 가지 객체 소멸자(finalizer, cleaner)를 제공
finalizer는 예측할 수 없고, 상황에 따라 위험할 수 있어 일반적으로 불필요
cleaner는 finalizer보다는 덜 위험하지만, 여전히 예측할 수 없고, 느리고, 일반적으로 불필요
finalizer와 cleaner로는 제때 수행되어야 하는 작업은 절대 할 수 없음
즉시 수행된다는 보장이 없고, GC 알고리즘에 달려있어 GC 구현마다 천차만별
상태를 영구적으로 수정하는 작업에서는 절대 finalizer, cleaner에 의존하지 말자
finalizer와 cleaner는 심각한 성능 문제도 동반
finalizer를 사용한 클래스는 finalizer 공격에 노출되어 심각한 보안 문제를 일으킬 수도 있음
final이 아닌 클래스를 finalizer 공격으로부터 방어하려면 아무 일도 하지 않는 finalize 메서드를 만들고 final로 선언하기
.
반납할 자원이 있는 클래스는 AutoCloseable을 구현하고, 클라이언트에서 close()를 호출하거나 try-with-resource를 사용하도록 하자.
public class AutoClosableIsGood implements Closeable {
private BufferedReader reader;
//...
@Override
public void close() {
try {
reader.close();
} catch (IOException e) {
throw new RuntimeException(e);
}
}
}
...
try (AutoClosableIsGood good = new AutoClosableIsGood()) {
//...
}
.
cleaner 와 finalizer 의 사용
(1). 자원의 소유자가 close 메서드를 호출하지 않는 것에 대비한 안전망 역할
PhantomReference 사용
호출되리라는 보장이 없지만 없는 것 보다는 나을 수 있음
(2). Native peer 와 연결된 객체에서 자원을 즉시 회수해야 한다면 close 메서드를 사용
성능 저하를 감당할 수 있고 네이티브 피어가 심각한 자원을 가지고 있지 않을 때에만 해당
네이티브 피어는 자바 객체가 아니라 가비지 컬렉터는 그 존재를 알지 못함
item 9. try-finally 보다는 try-with-resources를 사용하라.
꼭 회수해야 하는 자원을 다룰 때는 try-finally 말고, try-with-resources 를 사용하자.
예외는 없다. 코드는 더 짧고 분명해지고, 만들어지는 예외 정보도 훨씬 유용하다.
try-finally 로 작성하면 실용적이지 못할 만큼 코드가 지저분해지는 경우라도,
try-with-resources 로 정확하고 쉽게 자원을 회수할 수 있다.
📖
자원 닫기는 클라이언트가 놓치기 쉬워서 예측할 수 없는 성능 문제로 이어지기도 한다.
📝 복수의 자원을 처리하는 try-with-resources 는 짧고 매혹적
try-with-resources 구조를 사용하려면 해당 자원이 AutoCloseable 인터페이스를 구현해야 한다.
프로그래머에게 보여줄 예외 하나만 보존되고 여러 개의 다른 예외는 숨겨짐
숨겨진 예외들도 스택 추적 내역에 숨겨졌다는 꼬리표를 달고 출력
try-finally 는 마지막 발생 예외만 보여주고 숨겨진 예외는 알 수 없음
catch 절을 사용해서 다수 예외 처리 가능
/**
* try-finally
*/
InputStream in = new FileInputStream(src);
try {
OutputStream out = new FileOutputStream(dst);
try {
byte[] buf = new byte[BUFFER_SIZE];
int n;
while ((n = in.read(buf)) >= 0)
out.write(buf, 0, n);
} finally {
out.close();
}
} finally {
in.close();
}
...
/**
* try-with-resources
*/
try (InputStream in = new FileInputStream(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);
}
3장. 모든 객체의 공통 메서드
final이 아닌 Object 메서드(equals, hashCode, toString, clone, finalize)들을 언제, 어떻게 재정의해야 하는가
item 10. equals는 일반 규약을 지켜 재정의하라.
꼭 필요한 경우가 아니면 equals 를 재정의하지 말자.
많은 경우에 Object 의 equals 가 원하는 비교를 정확히 수행해준다.
재정의해야 할 때는 그 클래스의 핵심 필드 모두를 빠짐없이, 다섯 가지 규약을 확실히 지켜가며 비교해야 한다.
📖
equals 메서드의 재정의에는 함정이 도사리고 있는데, 이 문제를 회피하는 가장 쉬운 길은 아예 재정의를 하지 않는 것.
.
🔍 아래 상황 중 하나에 해당한다면 equals 메서드를 재정의하지 않는 것이 최선
각 인스턴스가 본질적으로 고유할 경우
인스턴스가 단 하나 존재하는 클래스 (ex. 싱글톤, Enum)
값 표현이 아닌 동작하는 개체를 표현하는 클래스 (ex. Thread)
인스턴스의 '논리적 동치성'을 검사할 일이 없을 경우
단순한 값 비교만으로 충분할 경우 (ex. 문자열)
상위 클래스에서 재정의한 equals 가 하위 클래스에도 적절할 경우
Set, List, Map 구현체들은 상속을 받아 그대로 사용
클래스가 private, package-private 이고 equals 메서드를 호출할 일이 없을 경우
equals 가 실수로라도 호출되는 것을 막고 싶다면 아래와 같이 구현해두자.
@Override public boolean equals(Object o) {
throw new AssertioniError(); // 호출 금지!
}
.
🔍 equals를 재정의해야 하는 경우
객체 식별성이 아닌 논리적 동치성을 확인해야 하는데, 상위 클래스의 equals 가 논리적 동치성을 비교하도록 재정의되지 않았을 경우
ex. 주로 값 클래스. Integer, String ..
equals 메서드를 재정의할 때는 반드시 일반 규약을 따라야 함
equals 메서드는 동치관계(equivalence relation)를 만족하며 다섯 가지 요건을 만족
동치관계: 집합을 서로 같은 원소들로 이뤄진 부분집합으로 나누는 연산
이 부분집합들을 동치류(equivalence class; 동치 클래스)라고 함
반사성(reflexivity)
A.equals(A) == true
null이 아닌 모든 참조 값 x에 대해, x.equals(x) == true
객체는 자기 자신과 같아야 한다.
대칭성(symmetry)
A.equals(B) == B.equals(A)
null이 아닌 모든 참조 값 x, y에 대해, x.equals(y)가 true면 y.equals(x)도 true
두 객체는 서로에 대한 동치 여부에 똑같이 답해야 한다.
equals 규약을 어기면 그 객체를 사용하는 다른 객체들이 어떻게 반응할지 알 수 없다.
다른 타입을 지원하면 문제가 복잡해지고 대칭성이 꺠지기 쉽다.
다른 타입을 지원하지 않고 대칭성을 만족
@Override public boolean equals(Object o) {
return o instanceof CaseInsensitiveString &&
((CaseInsensitiveString) o).s.equalsIgnoreCase(s);
}
추이성(transitivity)
A.equals(B) && B.equals(C) && A.equals(C)
null이 아닌 모든 참조 값 x, y, z에 대해, x.equals(y)가 true고, y.equals(z)도 true면 x.equals(z)도 true
구체 클래스를 확장해 새로운 값을 추가하면서 equals 규약을 만족시킬 방법은 존재하지 않는다.
public class ColorPoint extends Point {
private final Color color;
...
}
public class ColorPoint {
private final Point point;
private final Color color;
...
}
일관성(consistency)
A.equals(B) == A.equals(B)
null이 아닌 모든 참조 값 x, y에 대해, x.equals(y)를 반복해서 호출하면 항상 true 또는 false 반환
두 객체가 같다면 앞으로도 영원히 같아야 한다.
클래스가 불변이든 가변이든 equals의 판단에 신뢰할 수 없는 자원이 끼어들게 해서는 안 된다.
// 입력 타입은 반드시 Object (다중정의)
@Override public boolean equals(Object o) {
// 1. 반사성을 만족(필드들의 동치성만 검사해도 equals 규약을 어렵지 않게 지킬 수 있음)
if (o == this) return true;
// 2. 타입 비교
if (!(o instanceof PhoneNumber)) return false;
// 3. 타입 변환
PhoneNumber pn = (PhoneNumber)o;
// 4. 핵심 필드 비교
return pn.lineNum == lineNum
&& pn.prefix == prefix
&& pn.areaCode == areaCode;
}
Float.compare()와 Double.compare()을 제외한 기본 타입 필드는 == 연산자로 비교
참조 타입 필드는 각각의 equals 메서드로 비교
배열 필드는 원소 각각을 앞서의 지침대로 비교하고, 모든 원소가 핵심 필드라면 Arrays.equals 메서드들 중 하나를 사용
null 가능성이 있을 경우 Objects.equals(Object, Object) 비교로 NPE 방지
equals의 성능을 위해 다를 가능성이 더 크거나 비교 비용이 싼 필드를 먼저 비교
equals를 다 구현했다면 대칭적, 추이성, 일관적인지 자문
equals를 재정의할 땐 hashCode도 반드시 재정의
Object 외의 타입을 매개변수로 받는 equals 메서드는 선언하지 말자
.
equals, hashCode 메서드 자동 생성
item 11. equals를 재정의하려거든 hashCode도 재정의하라
equals를 재정의할 때는 hashCode도 반드시 재정의해야 한다. 그렇지 않으면 프로그램이 제대로 동작하지 않을 것이다.
재정의한 hashCode는 Object의 API 문서에 기술된 일반 규약을 따라야 하며, 서로 다른 인스턴스라면 되도록 해시코드도 서로 다르게 구현해야 한다.
📖
equals 를 재정의한 클래스 모두에서 hashCode 도 재정의해야 한다.
그렇지 않을 경우, hashCode 일반 규약을 어기게 되어 해당 클래스의 인스턴스를 HashMap 이나 HashSet 같은 컬렉션의 원소로 사용할 때 문제를 유발
Object 명세에서 발췌한 규약
equals 비교에 사용하는 정보가 변경되지 않았다면, hashCode 는 매번 같은 값을 리턴해야 한다.
equals 가 변경되거나, 애플리케이션을 다시 실행했다면 달라질 수 있다.
두 객체에 대한 equals 가 같다면, hashCode 값도 같아야 한다.
두 객체에 대한 equals 가 다르더라도, hashCode 값은 같을 수 있지만 해시 테이블 성능을 고려해 다른 값을 리턴하는 것이 좋다.
참고. 해시 충돌
다른 두 객체가 같은 hashCode를 가지고 Hash Collection에 저장될 때 해시 충돌 발생
해시 충돌이 발생하면 Hash는 값을 Object가 아닌 LinkedList로 저장
해시 조회 시 LinkedList를 순회하면서 equals 비교로 같은 인스턴스를 탐색
해시맵의 장점(O(1))이 없어지고 LinkedList를 사용하는 것과 동일(O(N))한 성능
java 8 에서 해시 충돌 개수가 8개를 넘어가면 LinkedList 대신 이진 트리(O(logN))를 사용하도록 개선
재정의 시 주의사항
성능 때문에 핵심 필드를 해시코드 계산할 시 제외하면 안 된다.
해시코드 계산 규칙을 API에 노출하지 않는 것이 좋다.
hashCode 메서드 재정의
/**
* lombok @EqualsAndHashCode
* - 사용 편의성 관점에서 권장하는 방법
* - 이미 테스트를 거친 상태이므로 테스트 불필요
*/
@EqualsAndHashCode
public class PhoneNumber {
}
/**
* IDE 에서 제공해 주는 hashCode 메서드
* - Objects 클래스의 hash 메서드
*/
@Override public int hashCode() {
return Objects.hash(lineNum, prefix, areaCode);
}
/**
* 전형적인 hashCode 메서드
* - 사전의 모든 단어에 31 을 사용했을 때, 해시 충돌이 가장 적었다는 연구 결과를 반영
*/
@Override public int hashCode() {
int result = Short.hashCode(areaCode); // 핵심 필드 하나의 해쉬값 계산
result = 31 * result + Short.hashCode(prefix);
result = 31 * result + Short.hashCode(lineNum);
return result;
}
/**
* 구글 구아바의 com.google.common.hash.Hashing
* - 좋은 성능을 가지고 있지만 hashCode 구현을 위해 라이브러리 추가 필요
* - https://mvnrepository.com/artifact/com.google.guava/guava
*/
@Override public int hashCode() {
return Hashing.goodFastHash(32)
.hashObject(this, PhoneNumberFunnel.INSTANCE)
.hashCode();
}
/**
* 해시코드를 지연 초기화하는 hashCode 메서드
* - 스레드 안정성을 위해 Double Checked Locking 기법 적용
* - volatile field: Thread-safety 한 변수
* - 보통 변수를 CPU cache 에 저장해서 예전 캐시 값을 읽어올 수도 있지만,
* - volatile 는 변수를 Main Memory 에 저장해서 가장 최근에 업데이터된 데이터를 참조
*/
private volatile int hashCode;
@Override public int hashCode() {
// First check outside synchronized
if (this.hashCode != 0) {
return hashCode;
}
synchronized (this) {
int result = hashCode;
// Second check in synchronized
if (result == 0) {
result = Short.hashCode(areaCode);
result = 31 * result + Short.hashCode(prefix);
result = 31 * result + Short.hashCode(lineNum);
this.hashCode = result;
}
return result;
}
}
item 12. toString을 항상 재정의하라.
모든 구체 클래스에서 Object의 toString을 재정의하자(상위 클래스에서 이미 알맞게 재정의한 경우는 예외)
toString을 재정의한 클래스는 사용하기도 즐겁고, 그 클래스를 사용한 시스템을 디버깅하기 쉽게 해준다.
toString은 해당 객체에 관한 명확하고 유용한 정보를 간결하고 읽기 좋은 형태로 반환해야 한다.
📖
Object의 toString은 클래스이름@16진수로 표시한 해시 코드
객체가 가진 보여줄 수 있는 모든 정보를 보여주는 것이 좋다.
값 클래스라면 포맷을 문서에 명시하는 것이 좋으며, 해당 포맷으로 객체를 생성할 수 있는 정적 팩터리나 생성자를 제공하는 것이 좋다.
toString이 반환한 값에 포함된 정보를 얻어올 수 있는 API(Getter)를 제공하는 것이 좋다.
경우에 따라 AutoValue, 롬복 또는 IDE를 사용하지 않는게 적절할 수 있다.
ex. 전화번호, 주소, 좌표, 위도, 경도 등 특정 포맷이 정해져있는 경우
📝 포맷을 명시한 경우
public final class PhoneNumber {
//..
/**
* 이 전화번호의 문자열 표현을 반환한다.
* 이 문자열은 "XXX-YYY-ZZZZ" 형태의 12글자로 구성된다.
* XXX는 지역 코드, YYY는 프리픽스, ZZZZ는 가입자 번호다.
* 각각의 대문자는 10진수 숫자 하나를 나타낸다.
*
* 전화번호의 각 부분의 값이 너무 작아서 자릿수를 채울 수 없다면,
* 앞에서부터 0으로 채워나간다. 예컨대 가입자 번호가 123이라면
* 전화번호의 마지막 네 문자는 "0123"이 된다.
*/
@Override public String toString() {
return String.format("%03d-%03d-%04d", areaCode, prefix, lineNum);
}
// 특정 포맷으로 객체를 생성할 수 있는 정적 팩터리나 생성자
public static PhoneNumber of(String phoneNumberString) {
String[] split = phoneNumberString.split("-");
PhoneNumber phoneNumber = new PhoneNumber(
Short.parseShort(split[0]),
Short.parseShort(split[1]),
Short.parseShort(split[2]));
return phoneNumber;
}
}
item 13. clone 재정의는 주의해서 진행하라.
Cloneable이 몰고 온 모든 문제를 되짚어봤을 때, 새로운 인터페이스를 만들 때는 절대 Cloneable을 확장해서는 안 되며, 새로운 클래스도 이를 구현해서는 안 된다.
final 클래스라면 Cloneable을 구현해도 위험이 크지 않지만, 성능 최적화 관점에서 검토한 후 별다른 문제가 없을 때만 드물게 혀용해야 한다.
기본 원칙은 '복제 기능은 생성자와 팩터리를 이용하는 게 최고!' 라는 것.
단, 배열만은 clone 메서드 방식이 가장 깔끔한, 이 규칙의 합당한 예외라고 할 수 있다.
📖
Cloneable을 구현한 클래스는 clone 메서드를 public으로 제공
사용자는 당연히 복제가 제대로 이뤄지리라 기대하지만, 깨지기 쉽고, 위험하고, 모순적인 매커니즘이 탄생..
.
clone 규약
x.clone() != x (clone은 원본과 다른 인스턴스)
x.clone().getClass() == x.getClass()
x.clone().equals(x) true가 아닐 수 있음 (객체마다 고유 식별자가 있을 경우)
.
📝 불변 상태를 참조하는 클래스용 clone 메서드
public final class PhoneNumber implements Cloneable {
// ...
@Override public PhoneNumber clone() {
try {
// 재정의한 메서드의 반환 타입은 상위 클래스의 메서드가 반환하는 타입의 하위 타입일 수 있다.
return (PhoneNumber) super.clone();
} catch (CloneNotSupportedException e) {
// checkedException → UncheckedException 변환
throw new AssertionError();
}
}
}
불변 객체라면 Cloenable 인터페이스를 구현하고, super.clone()를 사용해서 clone 메서드를 재정의하면 충분
접근 제한자는 public, 반환 타입은 자신의 클래스로 변경
Cloenable 인터페이스를 구현하지 않으면 CloneNotSupportedException 발생
clone 메서드는 사실상 생성자와 같은 효과
clone은 원본 객체에 아무런 해를 끼치지 않는 동시에 복제된 객체의 불변식을 보장해야 한다.
하지만, 정말 생성자를 사용하여 만든 객체를 반환하면 규약이 깨지게 된다.
하위 타입이 상위 타입을 받을 수 없는 cannot be cast to class 예외 발생
.
📝 가변 상태를 참조하는 클래스용 clone 메서드
public class Stack implements Cloneable {
private Object[] elements;
private int size = 0;
//...
@Override public Stack clone() {
try {
Stack result = (Stack) super.clone();
// elements 필드가 복사본과 같은 메모리를 참조하지 않도록 배열의 clone을 재귀적으로 호출
// 배열은 깊은 복사를 해주지 않으면 원본, 복사본 두 인스턴스가 동일한 배열을 참조
result.elements = elements.clone();
return result;
} catch (CloneNotSupportedException e) {
throw new AssertionError();
}
}
}
불변 상태를 참조하는 클래스용 clone 메서드와 기본적으로 동일
추가로, super.clone() 호출 후 필요한 필드를 적절히 수정
배열 복제 시 배열의 clone 메서드 사용, 필요 시 deep copy
public 고수준 메서드(get, put)를 호출하는 방법 존재
clone 메서드 내에서 하위 클래스가 재정의할 수 있는 메서드는 사용하지 않기
사용해야 한다면 재정의 불가능하도록 final 선언
상속용 클래스(abstract class)는 Cloneable을 구현하지 않기
Cloneable을 구현한 스레드 안전 클래스를 작성할 때는 clone 메서드에 synchronized 선언으로 동기화
단점
모호한 규약
필드에 final 사용 불가(clone 과정에서 필드 값 할당이 필요)
생성자를 사용하지 않다보니 생성자에 있는 필드 검증 작업을 거치지 않음
형변환 필요
.
복사 생성자와 복사 팩터리를 사용한 복사를 권장
문서화된 규약에 기대지 않고, 정상적인 final 필드 용법과 충돌하지 않고, 불필요한 검사 예외를 던지지 않고, 형변환도 필요하지 않음
해당 클래스가 구현한 interface 타입의 인스턴스를 인수로 받을 수 있음
클라이언트는 원본의 구현 타입에 얽매이지 않고 복제본의 타입을 직접 결정 가능
public TreeSet(Comparator<? super E> comparator) {
this(new TreeMap<>(comparator));
}
...
TreeSet<PhoneNumber> numbers = new TreeSet<>(Comparator.comparingInt(PhoneNumber::hashCode));
📝 복사 생성자 (변환 생성자, conversion constructor)
// 자신과 같은 클래스의 인스턴스를 인수로 받는 생성자
public PhoneNumber(PhoneNumber phoneNumber) {
this(phoneNumber.areaCode, phoneNumber.prefix, phoneNumber.lineNum);
}
📝 복사 팩터리 (변환 팩터리, conversion factory)
// 복사 생성자를 모방한 정적 팩터리
public static PhoneNumber newInstance(PhoneNumber phoneNumber) {
return new PhoneNumber(phoneNumber.areaCode, phoneNumber.prefix, phoneNumber.lineNum);
}
item 14. Comparable을 구현할지 고려하라.
순서를 고려해야 하는 값 클래스를 작성한다면 반드시 Compareable 인터페이스를 구현하여,
그 인스턴스들을 쉽게 정렬하고, 검색하고, 비교 기능을 제공하는 컬렉션과 어우러지도록 하자.
compareTo 메서드에서 필드의 값을 비교할 때, < 와 > 연산자는 쓰지 말자.
그 대신 박싱된 기본 타입 클래스가 제공하는 정적 compare 메서드나
Comarator 인터페이스가 제공하는 비교자 생성 메서드를 사용하자.
📖
알파벳, 숫자, 연대 같이 순서가 명확한 값 클래스를 작성한다면 반드시 Comparable 인터페이스를 구현하자.
Compareable 구현으로 수많은 제네릭 알고리즘과 컬렉션의 힘을 누릴 수 있다.
public interface Comparable<T> {
int compareTo(T t);
}
.
compareTo 규약은 equals 규약과 유사
단순 동치성 비교(Object.equals)에 더해 순서 비교가 가능하며 Generic 지원
반드시 따라야 하는 것은 아니지만 x.compareTo(y) == 0 이라면 x.equals(y) == true
BigDecimal oneZero = new BigDecimal("1.0");
BigDecimal oneZeroZero = new BigDecimal("1.00");
System.out.println(oneZero.compareTo(oneZeroZero)); // 0(Tree, TreeMap)
System.out.println(oneZero.equals(oneZeroZero)); // false(순서가 없는 콜렉션)
compareTo 규약을 지키지 못하면 비교를 활용하는 클래스와 어울리지 못함
.
compareTo 구현 방법 (Compratable 구현)
(1) 자연적인 순서를 제공할 클래스에 implements Compratable 선언
(2) compareTo 메서드를 재정의
(3) comprareTo 메서드 안에서 기본 타입은 박싱된 기본 타입의 compare을 사용해 비교
(4) 핵심 필드가 여러 개라면 비교 순서가 중요
순서를 결정하는데 있어서 가장 중요한 필드를 비교하고, 그 값이 0이라면 다음 필드를 비교
// (1) 자연적인 순서를 제공할 클래스에 implements Compratable<T> 선언
public final class PhoneNumber implements Comparable<PhoneNumber> {
private final short areaCode, prefix, lineNum;
//...
// (2) compareTo 메서드를 재정의
@Override
public int compareTo(PhoneNumber pn) {
// (3) comprareTo 메서드 안에서 기본 타입은 박싱된 기본 타입의 compare을 사용해 비교
int result = Short.compare(areaCode, pn.areaCode);
// (4) 핵심 필드가 여러 개라면 비교 순서가 중요
if (result == 0) {
result = Short.compare(prefix, pn.prefix);
if (result == 0)
result = Short.compare(lineNum, pn.lineNum);
}
return result;
}
기존 클래스를 확장하고 필드를 추가하는 경우 compareTo 규약을 지킬 수 없음
자식 클래스에서 Compratable 구현 불가
이 경우, Composition 활용
public class NamedPoint implements Comparable<NamedPoint> {
private final Point point;
private final String name;
// ...
@Override
public int compareTo(NamedPoint namedPoint) {
// Point 비교는 Point 클래스에서 재정의한 compareTo 사용
int result = this.point.compareTo(namedPoint.point);
if (result == 0) {
result = this.name.compareTo(namedPoint.name);
}
return result;
}
}
...
public class Point implements Comparable<Point>{
// ...
@Override
public int compareTo(Point point) {
int result = Integer.compare(this.x, point.x);
if (result == 0) {
result = Integer.compare(this.y, point.y);
}
return result;
}
}
.
compareTo 구현 방법 (Comprator 구현)
자바 8부터 함수형 인터페이스, 람다, 메서드 레퍼런스와 Comprator가 제공하는 기본 메서드, static 메서드를 사용해서 Comprator 구현 가능
자바의 정적 임포트 기능을 이용하면 정적 비교자 생성 메서드들을 그 이름만으로 사용할 수 있어 코드가 간결
Comparator가 제공하는 메서드 사용하는 방법
(1) Comparator의 static 메서드를 사용해서 Comparator 인스턴스 만들기
(2) 인스턴스를 만들었다면 default 메서드를 사용해서 메서드 호출(체이닝) 이어가기
static, default 메소드의 매개변수로는 람다 표현식 또는 메서드 레퍼런스 사용 가능
// (1) Comparator가 제공하는 static 메서드를 사용하여 Comparator 인스턴스 생성
private static final Comparator<PhoneNumber> COMPARATOR =
comparingInt((PhoneNumber pn) -> pn.areaCode)
// (2) 인스턴스를 만들었다면 default 메서드를 사용해서 메서드 호출(체이닝) 이어가기
.thenComparingInt(pn -> pn.prefix)
// static, default 메소드의 매개변수로는 람다 표현식 또는 메서드 레퍼런스 사용 가능
.thenComparingInt(PhoneNumber::getLineNum);
@Override
public int compareTo(PhoneNumber pn) {
return COMPARATOR.compare(this, pn);
}
...
@FunctionalInterface
public interface Comparator<T> {
// ...
default Comparator<T> thenComparingInt(ToIntFunction<? super T> keyExtractor) {
return thenComparing(comparingInt(keyExtractor));
}
}
자주 변하는 속성(외적인 속성, extrinsti)과 변하지 않는 속성(내적인 속성, intrinsit)을 분리하고 재사용하여 메모리 사용을 줄일 수 있음
public class Character {
private char value;
private String color;
private Font font;
}
...
public class FontFactory {
// Factory 클래스에 자주 사용하는 알고리즘을 캐싱
private Map<String, Font> cache = new HashMap<>();
public Font getFont(String font) {
if (cache.containsKey(font)) {
return cache.get(font);
} else {
String[] split = font.split(":");
Font newFont = new Font(split[0], Integer.paserInt(sptli[1]));
cache.put(font, newFont);
return newFont;
}
}
}
.
Java8 Interface / Item 01
자바 8부터는 인터페이스가 정적 메서드를 가질 수 없다는 제한이 풀렸기 때문에 인스턴스화 불가 동반 클래스를 둘 이유가 별로 없다.
빌더를 사용하면 (빌더의 각 메소드에 나눠서) 가변인수(varargs) 매개변수를 여러 개 사용할 수 있다.
public void printNumbers(int... numbers) {
System.out.println(numbers.getClass().getCanonicalName()); // int[]
System.out.println(numbers.getClass().getComponentType()); // int
Arrays.stream(numbers).forEach(System.out::println);
}
여러 인자를 받을 수 있는 가변적인 Argument (Var+args)
메소드에 오직 하나만 선언 가능
메소드의 가장 마지막 매개변수가 되어야 함
.
메서드 참조 / Item 03
메소드 하나만 호출하는 람다 표현식을 줄여쓰는 방법
// 익명 내부클래스 적용
people.sort(new Comparator<Person>() {
@Override
public int compare(Person a, Person b) {
return a.birthday.compareTo(b.birthday);
}
});
...
// 람다 표현식 적용
people.sort((a, b) -> a.birthday.compareTo(b.birthday));
스태틱 메소드 레퍼런스
public static int compareByAge(Person a, Person b) {
return a.birthday.compareTo(b.birthday);
}
people.sort(Person::compareByAge);
인스턴스 메소드 레퍼런스
public int compareByAge(Person a, Person b) {
return a.birthday.compareTo(b.birthday);
}
Person person = new Person();
people.sort(person::compareByAge);
임의 객체의 인스턴스 메소드 레퍼런스
첫 번째 인자를 자기 자신으로 인식(Person a 생략 가능)
public int compareByAge(Person b) {
return this.birthday.compareTo(b.birthday);
}
people.sort(Person::compareByAge);
// input:Integer, output: String
Function<Integer, String> intToString = (i) -> "hello";
Function<Integer, String> intToString = Object::toString;
/* 인터페이스 타입에 따라 각기 다른 생성자 참조 */
// output: Object (기본 생성자)
Supplier<Person> personSupplier = Person::new;
// input: LocalDate, output: Person (LocalDate 를 파라미터로 받는 생성자)
Function<LocalDate, Person> personFunction = Person::new;
// input: Integer
Consumer<Integer> integerConsumer = System.out::println;
// input: Person, output: boolean
Predicate<Person> predicate;
.
객체 직렬화 / Item 03
객체를 바이트스트림으로 상호 변환하는 기술
public class Book implements Serializable {
private static final long serialVersionUID = 1L; // serialVersionUID 선언
private String isbn;
private String title;
private LocalDate published;
private String name;
private transient int numberOfSold; // transient: 직렬화 제외
// constructor..
@Override
public String toString() {
//...
}
}
...
private void serialize(Book book) {
try (ObjectOutput out = new ObjectOutputStream(new FileOutputStream("book.obj"))) {
out.writeObject(book);
} catch (IOException e) {
throw new RuntimeException(e);
}
}
private Book deserialize() {
try (ObjectInput in = new ObjectInputStream(new FileInputStream("book.obj"))) {
return (Book) in.readObject();
} catch (IOException | ClassNotFoundException e) {
throw new RuntimeException(e);
}
}
public static void main(String[] args) {
Book book = new Book("12345", "이팩티브 자바 완벽 공략", "백기선",
LocalDate.of(2022, 3, 21));
book.setNumberOfSold(200);
SerializationExample example = new SerializationExample();
example.serialize(book);
System.out.println(book);
Book deserializedBook = example.deserialize();
System.out.println(deserializedBook);
}
Serializable 인터페이스 구현 필요
바이트스트림으로 변환한 객체를 파일로 저장하거나 네트워트를 통해 다른 시스템으로 전송 가능
transient를 사용해서 직렬화 하지 않을 필드 선언
serialVersionUID
미선언 시 JVM 런타임 시점에 자동으로 임의 UID 생성
직렬화 후 클래스가 변경되어도 역직렬화를 허용하려면 serialVersionUID 선언 필요
미선언 시 클래스가 변경될 경우 serialVersionUID도 자동으로 변경
.
생성자에 자원 팩터리를 넘겨주는 방식 / Item 05
자원을 만들어주는 팩토리를 통해서 자원을 가져오는 방식
만들어지는 과정이 복잡한 인스턴스일 경우 팩토리를 통해 생성
Supplier Interface 가 팩토리를 표현한 완벽한 예
public class SpellChecker {
private final Dictionary dictionary;
// 생성자에 자원 팩터리를 전달
// 한정적 와일드카드 타입을 사용해 팩터리의 타입 매개변수를 제한
public SpellChecker(Supplier<? extends Dictionary> dictionarySupplier) {
this.dictionary = dictionarySupplier.get();
}
//..
}
...
public class DictionaryFactory {
public static DefaultDictionary get() {
// Dictionary 구현체
return new DefaultDictionary();
}
}
...
SpellChecker spellChecker = new SpellChecker(DefaultDictionary::get);
.
팩터리 메소드 패턴 / Item 05
public class SpellChecker {
private Dictionary dictionary; // Dictionary Interface
public SpellChecker(DictionaryFactory dictionaryFactory) {
// 새로운 Product를 제공하는 팩토리(TempDictionaryFactory)를 추가해도
// 팩토리를 사용하는 클라이언트 코드는 변경할 필요가 없음
this.dictionary = dictionaryFactory.getDictionary();
}
//..
}
...
public interface DictionaryFactory {
Dictionary getDictionary();
}
...
public class DefaultDictionaryFactory implements DictionaryFactory {
// 구체적으로 어떤 인스턴스를 만들지는 서브 클래스가 결정
@Override
public Dictionary getDictionary() {
return new DefaultDictionary();
}
}
개방-폐쇄 원칙(Open-Closed Principle, OCP)
확장에 대해 열려 있고, 변경에 대해 닫혀있는 구조
Spring IOC 핵심인 Bean Factory가 대표전인 팩터리 메소드 패턴
.
Spring Ioc / Item 05
BeanFactory 또는 ApplicationContext
Ioc(Inversion of Control): 뒤짚힌 제어권
코드에 대한 제어권(인스턴스 생성, 메소드 실행, 의존성을 주입 등)을 자기 자신이 가지고 있지 않고 외부에서 제어하는 경우
Spring IoC Container 사용 장점
많은 개발자에게 검증되었으며 자바 표준 스팩(@Inject)도 지원
손쉽게 싱글톤 Scope 사용
객체 생성(Bean) 관련 라이프사이클 인터페이스 제공
.
Deprecation (사용 자제 API) / Item 06
클라이언트가 사용하지 않길 바라는 코드가 있다면 적용
/**
* @deprecated in favor of
* {@link #Deprecation(String)}
*/
@Deprecated(forRemoval = true, since = "1.2")
public Deprecation() {
}
private String name;
public Deprecation(String name) {
this.name = name;
}
