[BE] refactor: equals and hashcode 정의에 관하여 #520
Description
As-is
⚙️ 문제점: 롬북 사용해서 EqualsAndHashCode 를 재정의 하고 있다.
우선 객체가 양방향일 경우, ToString 에 순환참조에 대해 주의 해줘야 함
reflection 사용하기 때문에 성능상 느리다.
lombok 은 JPA 를 모르기 때문에 entity 내부에 있는 전체 필드를 검사해서 문제가 된다.
해결 방안
수동으로 재정의
⚙️Crew, Coach(Entity)에 왜 EqualsAndHashCode?
equalsAndHashCode 재정의는 동의한다. 그러나 위에 이슈로 entity는 직접 수동으로 재정의 해줘야겠다.
또한 영속성 컨텍스트가 같은 객체를 기준으로 id 값만 비교하기때문에 equals 기준으로 id 값만 비교하도록 하는게 좋겠다.
⚙️FormItems(일급 컬렉션에) 왜 EqualsAndHashCode?
일급 컬렉션도 도메인으로 사용하고 있기 때문에 해당 변화에 대해서 동등성, 동일성을 판단할 때가 있을 것 같다
따라서 수동으로 equalsAndHashCode 를 재정의 해주자
⚙️Answer, Question(VO)에 왜 EqualsAndHashCode?
값 객체는 그 값 자체에 대해서 Equals 를 했을 때, 동일성을 비교(주소값) 하는게 아니라
값 내용이 같은지 동등성에 대한 비교가 이뤄져야한다.
⚙️AvailableDateTimeResponse에 왜 EqualsAndHashCode?
dto 는 단순히 데이터를 전달하기 위한 객체라서 동일성과 동등성을 비교할 로직이 비지니스에 담겨 있지 않을 것 같아요.
현재 사용되는 코드드 전부 테스트 코드에 쓰이고 있고요. test code 를 위해서 재정의 해주는게 맞을까요 ?
그럼 어떤 객체에 Equals and HashCode 를 재정의 하면 안되는데?
서비스, controller, dto 등등 객체 자체의 필드에 값이 있고, 그 값이 변경되는 로직이 있는지,
변경되어 동등, 동일한지 판단하는 로직이 없다면 재정의하지 말아야한다.
To-be
각 객체의 책임에 맞게 lombok 빼고, 수동으로 변경한다.