장바구니 협업 미션 을 진행하며 도메인객체에 ID 필드를 넣어주었다.
public class Order {
private final Long id;
private final Integer price;
private final Member member;
private final CartItems orderedItems;
//...
}
도메인 객체가 ID를 갖고 있을 때의 장점과 단점을 비교해 보았을 때,
장점 쪽이 좀 더 마음에 와닿았기 때문이다.
도메인에 ID를 넣어주겠다는 것은 객체의 식별자로 ID를 사용하겠다는 의미이고,
ID를 통해 동등성을 보장하겠다는 의미이다.
처음에는 굳이 동등성을 보장할 필요가 없는 도메인 객체는 equals & hashcode를 재정의해주지 않았다.
필요하지가 않은데 굳이 할 필요가 있나 싶은 생각이었다.
equals & hashcode가 재정의 되지 않았는데 ID가 식별자 맞음?
위에서 말했듯 처음에는 객체간 동등성 비교가 필요한 도메인 객체에 한해서만 equals & hashcode를 재정의 했었다.
그런데 리뷰어가 다음과 같은 질문을 남겨주었다.
ID가 식별자일 때, 당장 사용하지 않는다고 equals & hashcode를 재정의하지 않는다면, 그 객체는 ID가 식별자라고 할 수 있을까요?
이 질문을 처음 봤을 때는 한번도 생각해보지 않은 부분이었어서, 머리가 조금 멍해졌었다.
ID를 필드에 넣어주긴 했지만, 실제로 equals & hashcode를 재정의 하지 않았기에, ID가 식별자로의 역할을 전혀 하고 있지 않다. 그저 필드에 ID가 있다고 ID는 식별자야.
라고 하는 거는 어디까지나 그냥 내 생각일 뿐 아무런 역할도 하고있지 않기 때문에 식별자라고 말하기는 무안한 상황이다.
하지만 여기까지만 생각했을 때도, 아니 뭐 그렇긴 한데... 필요할때 하면 되는거 아닌가..?
라는 생각이 좀 더 지배적이었는데. 리뷰어의 다음 질문을 통해 잘못된 생각을 하고 있음을 깨달았다.
사람은 제각각 코딩도 제각각
다른 개발자가 해당 객체를 HashMap을 이용하거나 하여 값을 비교하는 부분을 추가하려 할 때, equals & hashcode를 재정의해야함을 바로 알아볼 수 있을까요?
리뷰어가 남겨준 두번째 질문이다.
사실 이전 까지 내가 위와 같은 생각을 갖고 있었던 이유는 내 코딩 스타일 때문인 듯 하다.
나 같은 경우는 위에 리뷰어가 말한 객체를 HashMap을 이용하거나 하여 값을 비교하는 부분을 추가
해야 하는 상황이라면, 우선적으로 equlas & hashcode가 올바르게 재정의 되어있는지 확인하는 편이다.
남들도 다 그렇지 않나 싶어서 주변에 앉아있던 크루들에게 이런 경우 equals & hashcode 를 확인해보냐고 물어보니 true / false 의 비율이 거진 반반정도 되더라.
진짜 생각도 못했음.
정리
리뷰어와의 대화를 통해, 정리한 내용은 다음과 같다.
- 식별자는 사용하지 않아도 식별자여야 한다.
- equals & hascode 재정의는 어떠한 필드가 식별자인지 명확하게 해주는 역할도 있다.
- 위와 같은 이유로 사용여부와 관계없이 도메인을 생성할때, 식별자에 대한 여부는 명확히 잡고 가는 것이 혼동을 줄일 수 있다.
'Study > Java' 카테고리의 다른 글
Eager Loading & Lazy Loading (0) | 2023.07.16 |
---|---|
뒤늦게 공부해보는 함수형 인터페이스, 근데 이거 왜 씀? (0) | 2023.03.29 |
VARCHAR(20)에는 한글로 몇 글자까지 입력가능할까? (1) | 2023.03.27 |
어질어질 LinkedHashMap 복사하기 (0) | 2023.03.13 |
넌 지금 전혀 util 하고 있지 않아. (0) | 2023.03.12 |
댓글