@Builder 도대체 뭘 하는 녀석일까?

JPA를 사용하고 나서 @Builder를 쓰기 시작했는데 자세히 이게 무슨 역할을 하는지 몰랐었다.

 

그래서 오늘 간단하게 @Builder 어노테이션에 대해 정리를 해보려고 한다.

 

우선 JPA를 사용하고나서부터 패키지의 구조가 많이 변경됐다.

 

• Entity - DB 테이블과 1:1 매칭하는 클래스
• Repository - 해당 Entity에 대한 CRUD를 제공한다.
• Service - 기존에는 Service 인터페이스와 그걸 구현한 ServiceImpl 클래스를 만들었는데, JPA로 바꾸고 나서는 해당 Entity에 대한 클래스만 생성한다. Entity에 대한 비즈니스 로직을 수행한다.
• DTO - 클라이언트와 서버 간에 정보를 전송하기 위한 클래스다. Entity를 받아서 전송해도 되지만 문제점이 있다!
  1. 클라이언트와 데이터베이스 사이에 결합도가 증가한다!
  2. Entity는 테이블과 1:1 매칭되기 때문에 사용하지 않는 불필요한 정보까지 노출이 된다.
  그래서 Entity로 받지 않고 필요한 정보들로 만든 DTO를 사용한다.
• Controller - 클라이언트의 요청을 받고 응답을 보내주는 녀석!

나는 이렇게 구조를 만들어서 사용했다.

 

 

자 이제 @Builder가 어떤 마법을 부리는지 알아보자.

 

그러면 우선 간단하게 User Entity를 만들자.

@Getter @ToString
@Builer
public class User {

    @Id
    private String userId;
    private String name;
    private String email;
    private int age;
    
    생성자 생략..
}

총 5개의 정보를 받는 유저 Entity이다.

 

만약에 사용자한테 이름, 이메일, 나이만 정보를 받는다고 가정해 보자.

 

그러면 우리는 저 3개만 받는 DTO를 하나 설계해야 한다.

@Getter @Setter @ToString
public class UserDTO {
    private String name;
    private String email;
    private int age;
    
    생성자 생략..
    
    
    public User toEntity(){
        return User.builder()
                .name(name)
                .email(email)
                .age(age).build();
}

자 처음 보는 메서드가 하나 있다.

 

바로 toEntity()라는 녀석인데 이 녀석은 처음에 컨트롤러에서 DTO를 만들면 생성자 때문에 받는 정보가 저장되는데,

나중에 그걸 이용해서 Entity로 바꿔주는 녀석이다.(물론 이름은 내가 지은거니깐 편하게 지어도 된다.)

 

 

자 우선 예시 코드는 이 정도로 간단하게 알아보고

그러면 @Builder는 대체 뭘 해주는 녀석이냐?

 

기존에는 DTO를 받아서 Entity로 변경시키려면

User user = new User();
user.setName("인딥");
user.setEmail("indeep@naver.com");
user.setAge(27);

유저 객체를 하나 만든 다음에

그 객체에 set을 이용해서 하나하나 값을 바꿔줘야 했다.

 

하지만!!!!

 

우리는 이전에 Entity에 @Setter를 위험해서 사용하지 않았다. (무결성을 위해서)

 

Setter가 없으니 DTO를 Entity로 바꿔주기 위해서는 생성자를 이용하거나 빌더를 이용해야 한다.

 

그때 빌더를 사용하면

public User toEntity(){
        return User.builder()
                .name(name)
                .email(email)
                .age(age).build();

이런 메서드를 통해서 깔끔하게 Entity로 바꿀 수 있는 것이다.

 

JPA를 사용할 때 다른 사람들의 코드를 많이 찾아보니

전부 @Builder를 사용하더라.

 

조금씩 알아가면 좋은 어노테이션이라고 생각한다.

 

---

2024.05.05 추가

 

지금 보니 빌더에 대한 사용법만 적어두고 짜잔 하고 있네...뭔가 싶네

 

사실 빌더라는 패턴을 굳이 사용하지 않아도 된다.

 

UserDTO userDTO = new UserDTO("test", "test@naver.com", "박기현", 15);

이렇게 그냥 DTO를 생성자를 이용해서 만들어주면 문제 없다. 그런데 왜 많은 사람들이 빌더 패턴을 이용할까?

 

위 코드를 보면 ID, 이메일, 이름, 나이 순서대로 데이터를 할당해줘야 한다. 하나라도 순서가 바뀌면 생성에 문제가 생긴다.

그 이유는? 생성자는 오버로딩이 가능해서 순서가 바뀐 여러 생성자를 만들 수 있기 때문에 저 순서가 중요해지는 것.

 

근데 빌더 패턴을 이용하면 

 

1. 순서를 지키지 않아도 된다.

2. 가독성이 향상된다.

 

이 두 가지의 어마어마한 장점때문에 나도 애용하고 있는 편이다.

 

UserDTO build = UserDTO.builder()
                .age(15)
                .email("test@naver.com")
                .name("박기현")
                .id("test").build();

이게 같은 인스턴스를 생성하는 코드이다.

순서가 뒤죽박죽이어도 명시를 해놨기에 데이터가 문제 없이 할당되고, 또 어떤 데이터가 들어가는지 개발자가 한 눈에 알기 쉽다.

 

이러한 이유로 빌더 패턴을 많이 사용하는 것이다.