본문 바로가기
UMC 발자국

빌더 패턴 (Builder Pattern)

by 의정부핵꿀밤 2022. 4. 3.
728x90

발자국 서버 회의에서 블루가 객체를 생성할 때 @Setter를 사용하는 것보다 빌더 패턴을 사용하는 것이 더 좋다고 말해서 그렇게 리팩토링을 하고있다.

그러던 중 정확히 뭐가 좋은지 알아야 나중에 사용할 수 있을 것 같아서 간단하게 정리해보고자 한다!

 


[ 빌더 패턴(Builder Pattern)의 장점]

  • 필요한 데이터만 설정할 수 있다
    • 객체 생성 시 필요한 데이터가 변경되어도 동적으로 처리가 가능하다
    • 생성자 또는 정적 메소드와 비교하여 테스트용 객체를 생성할 때 용이하게 해준다
    • 불필요한 코드의 양을 줄여준다
  • 유연성을 확보할 수 있다
    • 빌더 패턴을 이용하면 새로운 변수가 추가되는 등의 상황이 생겨도 기존의 코드에 영향을 주지 않는다
    • 유연하게 객체의 값을 설정할 수 있다
  • 가독성을 높일 수 있다
    • 빌더 패턴을 사용하면 매개변수가 많아져도 가독성을 높일 수 있다
    • 직관적으로 어떤 데이터에 어떤 값이 설정되는지 쉽게 파악하여 가독성을 높일 수 있다
  • 변경 가능성을 최소화할 수 있다
    • Setter를 사용하면 불필요하게 변경 가능성을 열어두게 된다. 
    • 이는 유지보수 시에 값에 할당된 지점을 찾기 힘들게 만들고 그 지점을 찾기가 어려워 진다 (코드의 의도를 파악하기가 어려워짐)
    • 유지보수성을 높이려면 변경 가능성을 최소화해야 한다
    • 이를 위해서는 변수를 final로 선언함으로써 불변셩을 확보해야 한다. 하지만 경우에 따라 final을 붙히는게 어려울 수도 있기 떄문에 변경 가능성을 열어두지 않도록 Setter를 사용하지 않으면 된다!

 

 

[빌더 패턴이 필요없는 경우]

  • 객체의 생성을 라이브러리로 위임하는 경우
    • 엔티티 객체 또는 도메인 객체로부터 DTO를 생성하는 경우에는 직접 빌더를 만드는 작업이 번거로워 MapStruct나 Model Mapper와 같은 라이브러리를 통해 새성을 위임할 수 있다
  • 변수의 개수가 2개 이하이며, 변경 가능성이 없는 경우
    • 이 경우에는 빌더를 사용하면 오히려 코드가 비대해질 수 있기 때문에 다른 방법을 이용하는게 더 좋을 수 있다

 

 

 

728x90

댓글