본문 바로가기
Study/Java

도메인 객체의 equals & hashcode (feat. ID)

by dev_kong 2023. 6. 7.
728x90
728x90

장바구니 협업 미션 을 진행하며 도메인객체에 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 의 비율이 거진 반반정도 되더라.

 

진짜 생각도 못했음.

정리

리뷰어와의 대화를 통해, 정리한 내용은 다음과 같다.

  1. 식별자는 사용하지 않아도 식별자여야 한다.
  2. equals & hascode 재정의는 어떠한 필드가 식별자인지 명확하게 해주는 역할도 있다.
  3. 위와 같은 이유로 사용여부와 관계없이 도메인을 생성할때, 식별자에 대한 여부는 명확히 잡고 가는 것이 혼동을 줄일 수 있다.
728x90
728x90

댓글