builder를 쓰는 이유

필드만 선언한 경우

@Getter
@Entity
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class Todo {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String title;

    private String content;

    private String username;

    private String password;

    private LocalDateTime createdAt;
}

 

생성자와 @Builder 어노테이션을 추가한 경우

 

@Getter
@Entity
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class Todo {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String title;

    private String content;

    private String username;

    private String password;

    private LocalDateTime createdAt;

    @Builder
    public Todo(String title, String content, String username, String password, LocalDateTime createdAt) {
        this.title = title;
        this.content = content;
        this.username = username;
        this.password = password;
        this.createdAt = createdAt;
    }

    public void update(String title, String content, String username) {
        this.title = title;
        this.content = content;
        this.username = username;
    }
}

 

이렇게 선언했을때의 장점

 

1.객체 생성의 유연성

생성자와 @Builder 어노테이션을 추가한 경우:
@Builder 어노테이션을 사용하면 빌더 패턴을 통해 객체를 유연하게 생성할 수 있습니다. 빌더 패턴은 가독성이 좋고, 선택적으로 필드를 설정할 수 있어 코드의 유지보수성이 높아집니다.
생성자를 통해 필수 필드를 강제할 수 있습니다. 즉, 객체를 생성할 때 필요한 필드를 명확히 지정할 수 있습니다.

 

 

2. 코드의 가독성 및 유지보수성

생성자와 @Builder 어노테이션을 추가한 경우:

빌더 패턴을 사용하면 코드의 가독성이 높아지고, 유지보수성이 향상됩니다. 특히, 필드가 많을 때 유용합니다.
생성자를 통해 객체 생성 시 필수 필드를 명확히 지정할 수 있어, 코드의 안정성이 높아집니다.

필드만 선언한 경우:
객체 생성 시 필드를 일일이 설정해야 하므로 코드가 길어지고 가독성이 떨어집니다.
필수 필드를 강제할 수 없으므로, 객체 생성 시 실수로 필드를 빠뜨릴 가능성이 있습니다.

 

요약시

 

객체 생성의 유연성: 빌더 패턴을 사용하면 객체를 유연하게 생성할 수 있으며, 선택적으로 필드를 설정할 수 있어 코드의 가독성이 높아집니다.
필수 필드 강제: 생성자를 통해 객체 생성 시 필수 필드를 명확히 지정할 수 있어, 코드의 안정성을 높일 수 있습니다.
가독성 및 유지보수성 향상: 빌더 패턴을 사용하면 코드가 간결해지고, 필드가 많을 때도 가독성이 유지됩니다.

 

 

필드가 많을 때도 가독성을 위홰 사용

 

내림차순은 리포지터리에 작성