@Getter
@Setter // 문제 1. 객체가 무분별하게 변경될 가능성 있음
@NoArgsConstructor // 문제 2. 기본 생성자의 접근 제어자가 불명확함
@Builder
@AllArgsConstructor // 문제3. 객체 내부의 인스턴스멤버들을 모두 가지고 있는 생성자를 생성 (매우 위험)
@Entity
public class Member위 블로그에서는 해결방법을 다양하게 제시해준다.
해결방법1. @Setter을 사용하지 않는다.
의미있는 메서드로 생성한다.
의도가 분명하지 않고 객체를 언제든지 변경할 수 있는 상태가 되므로 객체의 안전성이 보장받기 힘들다. 특히 @Setter 사용시 어디에서 언제 누구에 의해 변경되었는지 추적하기 어렵다. 따라서 값 변경이 있는 경우 의미있는 메서드를 생성해 사용하는 것이 좋다.
해결방법2. @NoArgsConstructor(access = AccessLevel.PROTECTED)로 변경한다.
기본 생성자 (=@NoArgsConstructor)의 접근제어를 PROTECTED로 설정하면 아무 값도 갖지 않는 의미없는 객체 생성을 막을 수 있다. 무분별한 객체 생성에 대해 한번 더 체크할 수 있는 셈이다.
Member member = new Member(); //컴파일러 에러의미있는 객체 생성을 위해 @Builder를 사용할 수 있다. @Builder 사용방법은 총 2가지로, 1) 클래스에 @Builder 붙이기 2) 생성자에 @Builder 붙이기가 있다.
이건 다음 해결방법3에 소개하는 @AllArgsConstructor를 쓰지 않아야 하는 것과 관련이 있다.
해결방법3. @AllArgsConstructor 사용하지 않는다.
만약 해결방법2의 1) 클래스에 @Builder 붙이기를 사용한다고 해보자. 이때 클래스 레벨에서 @Builder와 @NoArgsConstructor를 함께 쓰면 오류가 발생하게 된다.
이를 해결하려고 모든 필드를 가진 생성자를 만들어주어야할텐데 @AllArgsConstructor도 쓰게 된다.
그러나 @AllArgsConstructor는 위험하다.
클래스에 존재하는 모든 필드에 대한 생성자를 자동으로 생성하는데, 인스턴스 멤버의 선언 순서에 따른 영향을 받기 때문에 변수의 순서를 바꾸면 치명적인 오류로 고통받을 수 있다.
