Open her0807 opened 2 years ago
우선 객체가 양방향일 경우, ToString 에 순환참조에 대해 주의 해줘야 함 reflection 사용하기 때문에 성능상 느리다. lombok 은 JPA 를 모르기 때문에 entity 내부에 있는 전체 필드를 검사해서 문제가 된다.
수동으로 재정의
equalsAndHashCode 재정의는 동의한다. 그러나 위에 이슈로 entity는 직접 수동으로 재정의 해줘야겠다. 또한 영속성 컨텍스트가 같은 객체를 기준으로 id 값만 비교하기때문에 equals 기준으로 id 값만 비교하도록 하는게 좋겠다.
일급 컬렉션도 도메인으로 사용하고 있기 때문에 해당 변화에 대해서 동등성, 동일성을 판단할 때가 있을 것 같다 따라서 수동으로 equalsAndHashCode 를 재정의 해주자
값 객체는 그 값 자체에 대해서 Equals 를 했을 때, 동일성을 비교(주소값) 하는게 아니라 값 내용이 같은지 동등성에 대한 비교가 이뤄져야한다.
dto 는 단순히 데이터를 전달하기 위한 객체라서 동일성과 동등성을 비교할 로직이 비지니스에 담겨 있지 않을 것 같아요. 현재 사용되는 코드드 전부 테스트 코드에 쓰이고 있고요. test code 를 위해서 재정의 해주는게 맞을까요 ?
서비스, controller, dto 등등 객체 자체의 필드에 값이 있고, 그 값이 변경되는 로직이 있는지, 변경되어 동등, 동일한지 판단하는 로직이 없다면 재정의하지 말아야한다.
각 객체의 책임에 맞게 lombok 빼고, 수동으로 변경한다.
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 빼고, 수동으로 변경한다.