@Data를 조심히 써야하는 이유

[YuDeokRin]

저번주에 @DaTa를 조심히 써야한다고 말은했지만 정확한 근거를 설명못해서 한번 같이 찾아보고 이야기 나눠보시죠

[seyxxn]

이번 강의에서 강사님이 간단하게 짚어주신 내용이네요 !
강의에서는 @Data 애노테이션이 Getter, Setter 등 많은 기능들이 자동으로 제공되기 때문에 주의해서 사용해야한다고 말씀해주셨습니다
조금 더 자세한 근거를 알고 싶어 정리해보았습니다 :)

@Data

• @Data = @toString + @getter + @setter + @RequiredArgsConstructor + @EqualsAndHashCode
  • @Data는 위의 여러 애노테이션을 합쳐놓은 애노테이션

문제점 1️⃣ : 무분별한 @setter 남용

• @Data에는 @setter이 포함되어있기 때문에, 의도가 불명확하고 변경하면 안되는 값임에도 불구하고 변경 가능한 값이라고 착각하고 변경할 수 있음 (안전성 보장 X)

문제점 2️⃣ : @RequiredArgsConstructor 사용으로 인한 문제점 (인스턴스 멤버 순서 변경)

@RequiredArgsConstructor과 @AllArgsConstructor

문제점 설명을 위해 두 애노테이션의 기능을 먼저 살펴볼 수 있다 (@Data에는 @AllArgsConstructor은 포함하지 X)

• @AllArgsConstructor : 객체 내부의 인스턴스 멤버들을 모두 가지고 있는 생성자를 생성하는 Lombok 애노테이션
• @RequiredArgsConstruct : 객체 내부의 final, @Notnull이 붙은 인스턴스 멤버들을 가지고 있는 생성자를 생성하는 Lombok 애노테이션

예시

@AllArgsConstructor
public static class Order {
    private long cancelPrice;
    private long orderPrice;
}
 
// 취소금액 5,000원, 주문금액 10,000원
Order order = new Order(5000L, 10000L);

• @AllArgsConstructor을 통해 자동으로 canclePrice, orderPrice 순서로 인자를 받는 생성자가 만들어진다
• 그런데 어느 개발자가 이 순서를 다음과 같이 바꿀 수 있다

@AllArgsConstructor
public static class Order {
    private long orderPrice;
    private long cancelPrice;
}

• 이 경우 Lombok이 개발자도 인식하지 못하는 사이에 생성자의 파라미터 순서를 필드 선언 순서에 맞춰 바꿔버린다 (orderPrice, canclePrice 순서가 된다.)
• 게다가 이 두 필드는 모두 동일한 long 타입이기에 오류가 발생하지도 않는다
• 이에 의해, 위의 생성자를 호출하는 코드는 아무런 에러없이 잘 동작하는 듯 보이지만 실제 값은 바뀌어 들어간다

// 주문금액 5,000원, 취소금액 10,000원. 취소금액이 주문금액보다 많아짐!
Order order = new Order(5000L, 10000L); // 인자값의 순서 변경 없음

• 이러한 문제는 두 애노테이션 모두 동일하게 존재한다

개선방법

• 위의 두 애노테이션을 이용하기보다는 직접 만든 생성자에 @Builder 애노테이션을 붙이는 것을 권장한다
• 파라미터 순서가 아닌 이름으로 값을 설정하기 때문에 리팩토링에 유연하게 대처할 수 있다

public static class Order {
    private long cancelPrice;
    private long orderPrice;
 
    @Builder
    private Order(long cancelPrice, long orderPrice) {
        this.cancelPrice = cancelPrice;
        this.orderPrice = orderPrice;
    }
}
 
// 필드 순서를 변경해도 문제 없음.
Order order = Order.builder().cancelPrice(5000L).orderPrice(10000L).build();

문제점 3️⃣ : 무분별한 @EqualsAndHashCode 사용금지

@EqualsAndHashCode

• equlas 메소드와 hashCode 메소드를 자동 생성하는 Lombok 애노테이션
  • equlas() : 두 객체의 내용이 같은지 동등성을 비교
  • hashCode() : 두 객체가 같은 객체인지 동일성을 비교
• 해당 객체가 불변 객체(immutable)라면 사용해도 좋지만, 변경 가능한(mutable) 객체라면 사용하지 않는 것이 좋다
  • 특히, 변경가능한 객체에 아무런 파라미터 없이 그냥 사용하는 @EqualsAndHashCode 애노테이션이 위험
  • @EqualsAndHashCode(of={“필드명시”}) 이렇게 파라미터를 추가하여 명시하는 형태로 사용해야 함

예시

@EqualsAndHashCode
public static class Order {
    private Long orderId;
    private long orderPrice;
    private long cancelPrice;
 
    public Order(Long orderId, long orderPrice, long cancelPrice) {
        this.orderId = orderId;
        this.orderPrice = orderPrice;
        this.cancelPrice = cancelPrice;
    }
}
 
Order order = new Order(1000L, 19800L, 0L);
 
Set<Order> orders = new HashSet<>();
orders.add(order); // Set에 객체 추가
 
System.out.println("변경전 : " + orders.contains(order)); // true
 
order.setCancelPrice(5000L); // cancelPrice 값 변경
System.out.println("변경후 : " + orders.contains(order)); // false

• 위 예시에서는 동일한 객체임에도 불구하고 저장한 뒤에 필드 값을 변경하면 hashCode가 변경되기 때문에 찾을 수 없게 되어 버림

HashSet은 contains로 검색 시, hashCode로 인덱스를 계산하여 검색함

개선

• 이를 방지하기 위해서는 @EqualsAndHashCode(of = {필드명})으로 동등성 비교에 필요한 필드를 지정해야 함

@EqualsAndHashCode(of = "orderId")
public static class Order {
    private Long orderId;
    private long orderPrice;
    private long cancelPrice;
 
    public Order(Long orderId, long orderPrice, long cancelPrice) {
        this.orderId = orderId;
        this.orderPrice = orderPrice;
        this.cancelPrice = cancelPrice;
    }

    // Getter and Setter
    public void setCancelPrice(long cancelPrice) {
        this.cancelPrice = cancelPrice;
    }
}

Order order = new Order(1000L, 19800L, 0L);
Set<Order> orders = new HashSet<>();
orders.add(order); // Set에 객체 추가

System.out.println("변경전 : " + orders.contains(order)); // true

order.setCancelPrice(5000L); // cancelPrice 값 변경
System.out.println("변경후 : " + orders.contains(order)); // true

🔎 참고한 글

[Spring] @Data 어노테이션
@Data 어노테이션 사용해야 되나?
Lombok 너무 편리하기 때문에 주의해야 한다. (Lombok 주의점)
Data에 대한 고찰
Lombok 사용상 주의점

[YuDeokRin]

어?! ㅋㅋ 제가 본 참고 글 내용이랑 똑같네요 ! ㅎㅎ