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