Effective Java 챕터2

🎯 Item 1: 생성자 대신 정적 팩터리 메서드를 고려하라

🔍 원문 요약

• 개념: 인스턴스를 얻는 전통적 방식인 public 생성자 대신, 정적 팩터리 메서드를 제공할 수 있음.
• 장점:
  • 이름을 가질 수 있어 의미 전달이 명확함.
  • 매번 객체를 새로 만들 필요 없음(인스턴스 통제).
  • 반환 타입의 하위 타입을 반환할 수 있음.
  • 매개변수에 따라 서로 다른 클래스 객체 반환 가능.
  • 작성 시점에 실제 구현 클래스가 없어도 되는 유연한 구조.
• 단점:
  • 생성자를 제공하지 않으면 하위 클래스 생성 불가.
  • 문서에서 생성자보다 검색이 어려울 수 있음.
• 명명 규칙: from, of, valueOf, getInstance, newInstance 등.

이어서

• 캐싱 전략 가능
• 스레드 풀·커넥션 풀처럼 제한된 자원 관리 가능
• 특정 조건에서 객체 재사용 가능
• API의 추상화를 강화해 캡슐화 수준 높임

---

🎯 Item 2: 생성자에 매개변수가 많다면 빌더를 고려하라

🔍 원문 요약

• 점층적 생성자 패턴은 가독성과 유지보수성이 떨어짐.
• 자바빈즈 패턴은 객체 완성 전까지 일관성이 깨지고, 불변성 보장이 어려움.
• 해결책: 빌더 패턴.
• 장점: 가독성·안정성·호환성 모두 뛰어남. 계층 구조 클래스에도 적합.

✨ 설명

new User(true, false, true, false, "A", null, 3, 5)

java
1User user = User.builder()
2    .name("홍길동")
3    .age(21)
4    .address("서울")
5    .marketingAgree(true)
6    .build();

---

🎯 Item 3: private 생성자나 열거 타입으로 싱글턴임을 보증하라

🔍 원문 요약

• 싱글턴 = 인스턴스 1개만 존재해야 하는 객체.
• 구현 방법:
  • public static final 방식
  • 정적 팩터리 방식
  • Enum 방식(가장 안전함)

✨ 설명

java
1public enum Settings {
2    INSTANCE;
3}

---

🔧 추가 예시: Effective Java 문서의 Elvis Enum 싱글턴 실제 코드

1) Enum 싱글턴 정의하기

java
1public enum Elvis {
2    INSTANCE; // 딱 한 개 존재하는 싱글턴 객체
3
4    // 일반 클래스처럼 메서드 정의 가능
5    public void leaveTheBuilding() {
6        System.out.println("Elvis has left the building!");
7    }
8}

2) 이렇게 호출해서 사용합니다

java
1public class Main {
2    public static void main(String[] args) {
3        // new Elvis() 같은 생성은 불가능 + 필요도 없음
4        Elvis.INSTANCE.leaveTheBuilding();
5    }
6}

📌 요약

• Elvis.INSTANCE = 싱글턴 객체 그 자체
• 생성자 호출 없음
• getInstance() 필요 없음
• 직렬화/역직렬화, 리플렉션 공격까지 기본적으로 안전함

---

🔐 추가로 알아야 할 점: 기존 싱글턴 방식이 위험했던 이유

1) 리플렉션 공격 취약점

java
1Constructor<Elvis> cons = Elvis.class.getDeclaredConstructor();
2cons.setAccessible(true);
3Elvis another = cons.newInstance();  // ❌ 싱글턴이 깨짐!

java
1if (alreadyCreated) throw new RuntimeException();

2) 직렬화(Serialization) 문제

java
1// 역직렬화 시 새 객체가 생성됨 → 싱글턴 파괴
2ObjectInputStream in = ...;
3Elvis e2 = (Elvis) in.readObject();

java
1private Object readResolve() {
2    return INSTANCE; // 기존 인스턴스 강제 반환
3}

---

🏆 결론: Enum 싱글턴이 왜 최종 솔루션인가?

• 리플렉션 공격 차단 → JVM 레벨 보안
• 직렬화/역직렬화 시 싱글턴 자동 보존 → 별도 코드 필요 없음
• 스레드 세이프 → 동기화 고려 불필요
• 코드 자체도 짧고 명확함

---

🎯 Item 4: 인스턴스화를 막으려거든 private 생성자를 사용하라

🔍 원문 요약

• 유틸리티 클래스는 인스턴스를 만들게 하면 안 됨.
• 컴파일러는 생성자가 없으면 자동으로 기본 생성자 추가 → 반드시 private 생성자를 명시해야 함.
• 실수 방지 및 상속 차단 효과.

✨ 설명

java
1public class MathUtils {}

java
1private MathUtils() {
2    throw new AssertionError();
3}

---

🎯 Item 5: 자원을 직접 명시하지 말고 의존 객체 주입(DI)을 사용하라

🔍 원문 요약

• 정적 유틸리티나 싱글턴에 의존하는 구조는 유연하지 않고 테스트하기 어려움.
• 해결책: 생성자에 필요한 자원을 주입하는 DI 구조.

✨ 설명

java
1SpellChecker checker = new SpellChecker(new DefaultDictionary());

java
1SpellChecker checker = new SpellChecker(testDictionary);

---

🎯 Item 6: 불필요한 객체 생성을 피하라

🔍 원문 요약

• 객체 재사용은 성능과 메모리 측면에서 매우 중요함.
• 문자열 리터럴 사용, Pattern 캐싱, 오토박싱 주의 등.

✨ 설명

java
1Pattern.matches(regex, input); // 매번 Pattern 생성

java
1private static final Pattern REGEX = Pattern.compile("...");

---

🎯 Item 7: 다 쓴 객체 참조를 해제하라

🔍 원문 요약

• Java라도 메모리 누수 가능.
• Stack·Cache·Listener/Callback 등에서 객체가 계속 참조되면 GC가 회수 불가.

✨ 설명

• 캐시 맵에서 값이 계속 누적됨
• 리스너 등록 후 해제하지 않음
• ThreadLocal 사용 후 remove() 호출 안 함

---

🎯 Item 8: finalizer와 cleaner 사용을 피하라

🔍 원문 요약

• finalizer/cleaner는 예측 불가능하고 성능에 악영향.
• 보안 문제까지 발생.
• 해결책: AutoCloseable + try-with-resources.

✨ 설명

• 언제 실행될지 알 수 없음
• 실행되지 않을 수도 있음
• GC와 결합되어 성능이 심각하게 떨어짐
• 안전하지 않음

java
1try (FileInputStream fis = new FileInputStream(path)) {
2    ...
3}

---

🎯 Item 9: try-finally보다는 try-with-resources를 사용하라

🔍 원문 요약

• try-finally는 코드가 지저분하고 예외가 덮일 위험 있음.
• try-with-resources가 더 안전하고 가독성 강함.

✨ 설명

java
1try {
2    InputStream in = ...
3} finally {
4    in.close();
5}

java
1try (InputStream in = ...) {
2}

---

🔎 추가 정리: 왜 try-with-resources가 반드시 필요할까?

---

1) 기존 방식(try-finally)의 문제점

1) 코드가 지저분함

java
1static void copy(String src, String dst) throws IOException {
2    InputStream in = new FileInputStream(src);
3    try {
4        OutputStream out = new FileOutputStream(dst);
5        try {
6            byte[] buf = new byte[BUFFER_SIZE];
7            int n;
8            while ((n = in.read(buf)) >= 0)
9                out.write(buf, 0, n);
10        } finally {
11            out.close();
12        }
13    } finally {
14        in.close();
15    }
16}

2) 예외 삼켜짐(Exception Masking) ← 가장 치명적

• try 블록에서 예외가 발생해 finally로 넘어갔는데,
• 거기서 close() 호출 시 또 예외가 발생하면…

---

2) try-with-resources는 무엇이 다른가?

java
1try (InputStream in = new FileInputStream(src);
2     OutputStream out = new FileOutputStream(dst)) {
3
4    byte[] buf = new byte[BUFFER_SIZE];
5    int n;
6    while ((n = in.read(buf)) >= 0)
7        out.write(buf, 0, n);
8}

✔ 코드가 매우 간결해짐

• 중첩 없음
• 가독성 높음
• 유지보수 편함

✔ 예외 처리 품질이 압도적으로 좋아짐

• 가장 처음 발생한 예외가 메인 예외로 유지됨
• close() 중 발생한 예외는 suppressed 예외로 함께 기록됨
• 디버깅 시 모든 정보가 남아 정확한 원인 파악 가능

---

3) 사용 조건

• InputStream, OutputStream, Connection, PreparedStatement 등 자바 라이브러리 대부분의 자원은 이미 구현되어 있음.

---

📌 정리

• try-finally는 예외를 덮어버리기 때문에 위험함
• 복잡한 자원 관리 코드가 간결하게 정리됨
• 디버깅 품질이 좋아지고 유지보수성이 뛰어남
• 자바 7 이후로는 사실상 필수 표준 방식