안전한 Lombok 사용법

@Data 지양

@Data는 많은 어노테이션들(@ToString, @EqualsAndHashCode, @Getter, @Setter, @RequiredArgsConstructor)을 갖고 있는 어노테이션이다. 그만큼 강력하고 편리하지만 그에 비례하여 부작용도 많아 사용 시 주의를 기울여야 하는 어노테이션이다.

@Setter남용

@Data에는 @Setter가 포함되어 있기 때문에 객체를 언제든 변경할 수 있는 상태가 된다.
그만큼 객체의 안정성이 보장받기 어렵게 된다.

@ToString으로 인한 양방향 연관관계시 순환 참조 문제

두 엔티티가 서로 양방향 연관관계일 때 @ToString을 호출하면 무한히 순한 참조가 발생한다.

해결방법

엔티티 선언 시 @ToString(exclude="{순환참조 되는 필드}")를 사용한다.
exclude옵션을 사용하면 ToString에서 특정 필드를 제외할 수 있다.

@Data 어노테이션은 ReadOnly객체(VO, DTO)에만 선언

바람직한 방법

@NoArgsConstructor접근 권한 최소화

@NoArgsConstructor(access = AccessLevel.PROTECTED)
JPA에서는 프록시 생성을 위해 기본 생성자를 반드시 하나 생성해야 한다.
이때 protected가 아닌 public으로 선언한다면 문제가 발생한다.
테스트 코드 등 다른 코드에서 파라미터가 있는 생성자가 아니라 기본 생성자를 호출했을 때 엔티티의 필드 중 null필드가 발생할 가능성이 생긴다.
이는 객체 생성 시 안전성을 심각하게 떨어뜨린다.

Builder 사용시 매개변수 최소화

엔티티에서 @Builder 사용 시 @AllArgsConstructor어노테이션을 붙인 효과와 같은 효과를 볼 수 있다.
하지만 builder는 모든 멤버 필드에 대한 매개 변수를 받게 되는 문제가 있다.
예를 들어 id의 경우 특정 생성 전략을 따라야 한다면 파라미터로 받지 않아야 한다.
또 createAt, updateAt과 같은 필드도 파라미터로 받지 않아야 하는 필드에 해당한다.

해결 방법

public class Member {

    @Builder
    public Member(String email, String name) {
        this.email = email;
        this.name = name;
    }
}

위처럼 파라미터로 받아야하는 필드만 지정하여 builder를 만들어 주는 방식이 바람직하다.

출처:
실무에서 Lombok 사용법

"본 포스트는 작성자가 공부한 내용을 바탕으로 작성한 글입니다.
잘못된 내용이 있을 시 언제든 댓글로 피드백 부탁드리겠습니다.
항상 정확한 내용을 포스팅하도록 노력하겠습니다."