객체 동등성을 위한 equals, hashcode -> 롬복 또는 직접 정의

[CheChe903]

.

[minSsan]

@2Jin1031 칼리의 요청에 따라 오프라인 회의에서 언급한 내용들 코멘트로 정리해두겠습니다!

---

저는 엔티티 정의를 떠올렸을 때, id 값이 null인 객체를 서로 비교한다는 상황에 공감이 잘 안 됐어요~! 🥲
그래서 제가 생각하는 엔티티의 정의를 통해 공감이 안된 이유를 설명해볼게요 ,,~

Entity 정의

엔티티가 왜 생겨났는가?!
바로 어플리케이션 생명 주기를 넘어서 데이터를 관리해야 할 요구사항이 생겨났기 때문이다!

식별자 없이 데이터를 영구적으로 어떻게 관리할 수 있을까?
("값이 변화했음에도 정체성은 변하지 않았음"을 어떻게 알 수 있는가? 바로 id 값이다!)

반대로도 생각해보면 id 값이 존재하지 않는다는 것은 해당 데이터를 영속하지 않았다는 뜻으로도 볼 수 있다. (= 영구히/장기간 저장하고자 하는 요구가 없음)

• 즉, 영속되지 않은 데이터는 엔티티로서 관리할 관심이 없다는 것
  • 엔티티로서 데이터를 관리한다는 것은? 👉🏻 id 값을 기준으로 엔티티의 정체성을 비교/확인하는 것이 아닐까??

엔티티로 데이터를 다룬다는 것은 결국 id 값으로 정체성을 비교하려는 욕구에서 시작되는 것인데, 이러한 욕구가 존재하지 않는(= id가 null) 상황에서 둘의 정체성을 비교하는 상황이 존재할 수 있나?!
이 상황을 마주했다는 것 자체가 엔티티를 잘못 사용한 것일 수도 있지 않나?

라는 생각이 들면서 공감이 안 됐던 것 같습니다 ..~

Set 예시 관련

오프라인 회의에서 언급되었던 "엔티티를 영속하기 전에 Set 자료구조를 활용해야 하는 상황" 에 대해서도 다시 생각을 해봤는데요
이러한 요구사항이 필요하다는 것은 결국 중복되는 요청으로 인해 중복되는 데이터가 입력되면 안 되는 상황인 것 같아요 ~

그런데 저는 이 시나리오를 딱 들었을 때, "데이터의 중복" 확인을 엔티티를 통해서 비교를 하는게 맞는가? 라는 의문이 들었어요.
애초에 데이터 값의 중복을 확인해야 한다면, 영속 이전 단계에서 이뤄져야 하는게 아닌가?

영속 이전 단계 = 엔티티로 다루지 않음

데이터 값을 비교한다는 것은 엔티티보단 VO 특성에 더 가깝다고 생각해서, 중복된 요청을 막는 목적이라고 한다면 저는 차라리 엔티티가 아니라 Request VO를 서로 비교할 것 같아요