메서드 활용 패턴 (중급)

2. 핵심 원리

2.1 생성자의 한계와 정적 팩토리

생성자는 이름이 클래스 이름으로 고정되어 있습니다. new Money(1000)이 원인지 달러인지, new Point(3, 4)가 직교좌표인지 극좌표인지 알 수 없습니다. 같은 시그니처의 생성자를 두 개 둘 수도 없습니다. 정적 팩토리 메서드(static factory method)는 이 한계를 넘습니다.

관례적 이름: of(값을 감싸기), from(다른 타입에서 변환), valueOf(of와 같지만 캐시 가능성), getInstance/newInstance, create. 생성자를 private으로 막고 정적 팩토리만 열어 두면 "만드는 방법"을 클래스가 완전히 통제합니다.

2.2 빌더 — 매개변수가 많을 때

매개변수가 4개를 넘고 그 중 일부가 선택 사항이면 생성자 오버로딩은 조합 폭발을 일으킵니다(점층적 생성자 패턴). 빌더(builder)는 필수 값은 빌더 생성자로, 선택 값은 이름 있는 메서드로 받아 build()에서 검증하고 객체를 만듭니다.

Order.builder("Kim")        ← 필수 인자
     .item("노트북")          ← 선택, return this
     .address("부산")         ← 선택, return this
     .build()               ← 검증 후 불변 Order 생성

return this가 체이닝을 가능하게 합니다. 각 setter가 자기 자신(빌더)을 돌려주므로 .을 계속 이어 쓸 수 있습니다.

2.3 디스패치 — 어떤 메서드가 실행되는가

템플릿 메서드가 동작하는 원리가 바로 런타임 디스패치입니다. 부모의 generate()가 header()를 호출하면, this의 실제 타입(CsvReport)의 header()가 실행됩니다. 부모는 자식이 누구인지 몰라도 됩니다.

2.4 반환값 설계 — 실패를 어떻게 알리는가

"찾는데 없을 수 있다"는 Optional, "입력이 잘못됐다"는 예외 또는 Result, "목록이 비었다"는 빈 컬렉션. 이 세 가지만 지켜도 API가 명확해집니다.

2.5 별칭(aliasing)과 방어적 복사

객체는 주소로 전달되므로, 생성자에서 받은 리스트를 그대로 필드에 넣으면 바깥 코드가 그 리스트를 바꿀 때 내 객체의 상태도 바뀝니다. 이를 별칭 문제라 합니다. 해결책은 두 방향의 복사입니다.

바깥 → 안 (생성자/setter):  this.items = new ArrayList<>(items);   방어적 복사
안 → 바깥 (getter):        return Collections.unmodifiableList(items);   불변 뷰
                            return List.copyOf(items);                   불변 복사

unmodifiableList는 원본이 바뀌면 같이 바뀌는 뷰이고, List.copyOf는 그 순간의 스냅샷입니다. 둘 다 바깥에서 add하면 UnsupportedOperationException입니다.

2.6 표준 메서드 4종의 계약

record는 이 중 equals/hashCode/toString을 자동 생성합니다. 직접 클래스를 쓸 때는 Objects.equals, Objects.hash, Long.compare를 사용해 실수를 줄입니다.