[BE] DTO 생성 디자인패턴 회의

📘 회의 주제

코드리뷰 중 두 백엔드 개발자 간 DTO생성방식이 다른 점을 발견하였습니다. - UNIRO-64 PR

코드 통일성을 위하여 두 방식 중 어떤 방식이 이 프로젝트에 더 어울릴지 회의를 통해 결정하게 되었습니다.

💻 기존의 다른 두 코드

@Builder
public class exampleDTO {
    private String var;
}

@RequiredArgsConstructor
public class exampleDTO {
    private final String var;

    public static exampleDTO of(String var){
        return new exampleDTO(var);
    }    
}

❗ 의견

• 빌더패턴을 사용한 이유 및 장단점

  1. 가독성 - DTO를 생성할 때 변수명을 명시하기 때문에 어떤 변수에 어떤 값이 들어가는지 명확하게 확인할 수 있습니다.
  2. 편의성 - DTO 재사용 시 생성자의 오버로딩, DTO 필드의 확장 이 두 과정이 간단하다.
  3. 단점 - 특정 필드를 누락한 경우 문제가 생길 수 있고, 이를 방지하는 코드를 작성해야하는 경우 위 두 장점이 상쇄된다.

• 팩토리메서드를 사용한 이유 및 장단점

  1. 생성 과정의 캡슐화 - 객체 생성 과정을 한 곳에 집중시킬 수 있다.
  2. SRP - 생성 로직이 분리된다.
  3. 확장성 - 새로운 유형의 객체가 필요할 때 팩토리메서드 추가로 간단하게 해결할 수 있다.
  4. 단점 - 구현 복잡성 증가

🚀 정리

팩토리 메서드 패턴의 장점이 이 프로젝트에 더 적절한 것 같다고 판단하였습니다.
다만, 현재 팩토리 메서드 코드는 public 생성자와 static 팩토리 메서드가 공존하기 때문에,
팩토리 메서드 패턴의 장점이 제대로 발휘되지 않고 있습니다.

따라서, 생성자를 private으로 제한하여 객체 생성을 팩토리 메서드로만 일원화함으로써,
객체 생성 로직의 캡슐화와 중앙화를 통해 유지보수성과 확장성을 더욱 강화하도록 코드를 통일하였습니다.

💻 개선 후 코드

public class exampleDTO {
    private final String var;
    
    private exampleDTO(String var){
        this.var = var;
    }

    public static exampleDTO of(String var){
        return new exampleDTO(var);
    }    
}