위처럼 (DB의 PK값, 출발역, 도착역, 거리)를 가지는 경로(Path) 객체가 있다.
같은 Path 끼리의 동등성을 비교해야 하는 상황이 있다.
이때 처음에는 다음과 같이 생각했다.
도메인 비즈니스를 수행하는 도메인 객체이지만 DB의 식별자를 가지는 엔티티이므로 ID값만을 비교해야 하지 않을까?
그리하여 ID만을 비교하는 Equals & HashCode 를 오버라이딩 했다.
하지만 DB에 저장되지 않은 상태라면,
ID가 null인 상태의 객체라면 도메인 로직 수행이 불가능해진다.
위의 도메인 객체가 영속 여부와 관계 없이 우리의 비즈니스를 수행할 수 있으면 좋겠다고 생각했다.
그래서 영속 여부에 따라서 고유성을 비교할 지, 속성들을 비교할 지 정해줬다.
현재의 인스턴스가 영속 객체라면 고유성을 비교하고, 그게 아니라면 VO처럼 속성들을 비교해줬다.
하지만 ID값이 없는 객체와 ID값이 있는 객체를 비교한다면…?
둘의 속성이 모두 같으면 파라미터로 들어온 객체는 영속 상태임에도 불구하고 현재 객체와 동등하다고 판단된다.
또한 hashCode의 경우는 ID값에 대한 분기를 다루지도 않았다.
문제가 발생할 여지가 충분한 코드임에도 인지하지 못했던 것 같다.
그렇다면 비즈니스 로직에서 두 객체를 비교해야 할 때, Equals, HashCode를 어떻게 재정의 해야 할까?
사실 VO처럼 속성의 동등성과 DB의 PK처럼 동일성 모두를 하나의 메서드로 비교하기 위해서 발생하는 문제라고 생각된다.
우선 이 객체를 DB의 고유성을 만족하는 엔티티로 정의한다면,
이렇게 ID만을 비교해야 한다.
엔티티는 ID의 고유성으로 (같다, 다르다)가 구분되기 때문이다.
그리고 속성의 동등함을 비교해야 할 때는,
이렇게 새로운 메서드를 만들어주는 것이 위에서 언급해왔던 equals 메서드의 동작 모호함도 해결하고, 가독성 측면에서도 더 좋다고 생각한다.
