프로젝트 진행하며 Pdf 정보를 응답으로 보내야 했다.

별도의 PdfResponse를 만들고 Builder 패턴으로 만들었다.

또한 Domain Pdf를 활용해 응답을 만들어야 했다.

그렇기에 다음과 같이 정적 팩토리 메서드를 활용했다.

public static PdfResponse from(Pdf pdf) {
    return PdfResponse.builder()
            .id(pdf.getId())
            .indexPath(pdf.getIndexPath())
            .maxQuizCount(pdf.getMaxQuizCount())
            .createdAt(pdf.getCreatedAt())
            .build();
}

 

이렇게 사용하면 좋다고 해서 사용하는데 왜 그런지 자세히 알아보자

 

먼저 정적 팩토리 메소드는 디자인 패턴이 아니다.

객체 생성 기법 중 하나이다.

생성자를 대체할 방법 중 하나

 

왜 만들어졌나

생성자는 제약이 많고, 유연성이 부족

  • 생성자는 클래스 명으로 메서드를 만들어야해 오버로딩 시 구분 어려움
  • 항상 새 객체 생성하기에 재사용 어려움
  • 하위 타입 반환 어려움

이러한 제약을 정적 팩토리 메소드는 해결할 수 있다.

여러 방식이 있어서 아래의 장점을 모두 가지지는 않는다.

방식마다 아래의 장점 중 일부를 가지게 된다.

  • 이름 부여
  • 객체 재사용 가능
  • 하위 타입 반환 가능
  • 생성자보다 유연한 오버로딩
  • 불필요한 부분 가리는 캡슐화

이름 부여

생성자는 모두 같은 이름을 사용해야해 구분이 힘들었다.
하지만 정팩메는 메서드 이름으로 의미를 알 수 있다.

또한 대표적인 네이밍 패턴으로 구분하기 편하다.

메서드 이름 의미 예시
of(...) 값 기반 간단한 생성 User.of(name, age)
from(...) 다른 객체나 타입 → 변환 UserDto.from(User)
valueOf(...) 문자열 등에서 객체 변환 Enum.valueOf("ACTIVE")
getInstance() 싱글턴, 캐시 객체 반환 Logger.getInstance()
newInstance() 매번 새로운 객체 생성 UUID.newInstance()
create() / build() 생성 과정 복잡할 때 Order.create(...)

 

그 전에 봤던 건 getInstance()로 싱글턴 패턴 구현할 때 사용했었다.

내가 이번에 사용한 메서드 이름은 from이다. 이건 다른 객체을 변환해 별도의 객체로 만드는 작업이다.

이러한 방식은 생성자 오버로드를 별도로 할 필요 없이 사용할 수 있고, 빌더를 내부로 숨겨 캡슐화 할 수 있었다.

이 접근은 생성자 오버로드를 줄이고, 내부적으로 builder를 사용하되 외부에 노출하지 않음으로써
객체 생성 로직을 캡슐화하고 코드의 명확성과 일관성을 높일 수 있었다.

 

이러한 정팩메도 단점은 존재한다.

단점

  • 제대로된 정팩메를 위해 생성자를 가려야 한다(private, protected) -> 상속에서 힘듦
  • new 키워드처럼 직관적이지 않음
  • 문서 없으면 숨겨져 있어서 사용 힘듦

상속이 힘든 부분은 생성자도 같이 사용해 어느 정도 완화할 수는 있다.

목적에 맞게 사용하면 되기 때문

 

마무리

오늘은 프로젝트를 진행하며 정팩메라는 것을 알게 되었고, 왜 사용하는지, 언제 사용해야 되는지 알아봤다.

일단 이번 상황에서는 객체를 변환하는데 사용되었지만, 다른 경우로 사용될 때도 그때 그때 정리하면서 완성해 나가야겠다.

+ Recent posts