1. CustomBeanUtils 레퍼런스

• 레퍼런스 코드 원본

• 사용 목적

  Patch 엔티티에 null 값이 들어왔는지 일일히 필드 별로 확인하기 귀찮기 때문에 CustomBeanUtils를 사용했다. 하지만 엔티티에 Setter를 사용한다는 점이 거슬린다.

• 해결 방법

  애초에 값이 null으로 들어왔는지 체크할 필요가 없도록 입력값에 필수를 두어 제한한다. 그리고 해당 입력값들에 대해서만 값 변경을 수행하면 된다.

  사용자로부터 PatchDto를 전달 받을 때, 서비스 단에서 PatchDto에 null 필드가 있는지 확인할 필요가 없도록.

2. Entity Setter 사용을 권장하지 않는 이유

1. Setter를 무분별하게 남용하면 객체의 값을 여기저기서 변경할 수 있어서 일관성이 보장되지 않는다.
2. 의도를 알기 힘들다.
   • 왜 값을 setter로 변경하는지 알 수 없다.
   • 객체에 메서드를 제공해 변경하면 의도를 알 수 있고, 객체 자신이 자신의 값을 변경한다는 점이 객체지향 관점에도 더 알맞다. (멘토님도 언급해주셨던 Entity 클래스 내 메서드)

3. Setter 사용을 줄이는 방법 - 불변 객체

애초에 불변 객체처럼 사용한다면 Setter 사용을 줄일 수 있다.

생성 메서드 setter 질문 - 인프런 | 질문 & 답변

• 객체의 일관성을 유지하기 위해 객체 생성 시점에 값들을 넣어 Setter 사용을 줄일 수 있다.

1. 생성자
2. 빌더패턴
3. 정적 팩토리 메소드

• 정적팩토리메서드, 빌더패턴을 사용할 땐 생성자를 private 처리한다.

• 기본생성자 접근자를 protected로 변경해 외부에서의 new 연산자 사용을 막을 수 있어 객체의 일관성을 유지할 수 있다.

  • JPA 기본 스펙 상 기본생성자가 필요한데, protected로 제어하는 것 까지 허용된다.
  • 롬복의 @NoArgsConstructor(access = AccessLevel.PROTECTED) 으로 간단히 설정할 수 있다.

  [JPA] 왜 JPA의 Entity는 기본 생성자를 가져야 하는가?

  Reflection API 간단히 알아보자.

4. Entity 내 메서드 - 가변 객체 (무분별한 Setter 사용 X)