[Item11] @EqualsAndHashCode

Item11은 equals 재정의할 때 hashCode도 반드시 재정의하라는 내용이다

equals를 직접 작성하고 싶어서 안달이 난 게 아니라면 그냥 롬복이 제공하는 걸로 쓰자

자바는 안 그래도 boiler plate 때문에 코드 길이가 긴 놈인데 

코드 흥선대원군 마냥 롬복을 쓰지 않겠다면 프로젝트 코드가 금세 팔만대장경 뺨 칠 수준이 될 것이다

특히 이는 알고리즘 문제 풀 때 C++, python과 비교해보면 코드 길이 차이가 체감이 된다

한 달 전쯤 잠깐 코틀린 인 액션 한 바퀴 돌리면서 코틀린 좀 핥아봤는데 많은 문제가 개선된 것 같다

아직까지는 대규모 프로젝트에 도입하기엔 이른 감이 없지 않은데 네카라쿠배당토가 힘내서 레퍼런스 뿌려주면 좋겠다

 

이전 장에서 @EqualsAndHashCode 사용할 때 성능 저하가 올 수 있다는 점을 언급했는데

이에 대해 조금 찾아보니 롬복 때문에 일어나는 문제라기 보다 개발자의 부주의에 의해 일어나는 문제다

롬복은 annotation-processor에 의해 컴파일 타임에 훅을 걸어 코드를 만들어 내는 놈이라

런타임에는 아무런 작용도 없어 성능 저하가 일어나지 않는다

@EqualsAndHashCode 로 hashCode 생성할 때 값을 얻을 필드로

양방향 연관관계가 걸려 있는 놈을 선택하면 엔티티 간

양방향 걸려있는 필드 두 놈의 무한 hashCode 호출로 프로그램이 터질 수 있다

 

이는 equals, hashcode 생성 시 들어갈 필드를 제대로 고르지 못한 개발자의 잘못이다

엔티티를 식별할 수 있도록 유니크한 값이거나 중복이 적은 여러 개의 필드를 선택해야 한다

또한 그 필드는 값 변경이 되도록 적어야 한다

 

얼마 전 코드리뷰 받은 내용으로 엔티티의 식별자는 equals, hashcode에 사용하기 적합하지 않다고 한다

식별자는 기본키이므로 당연하게도 중복이 없으니 이 놈이 비교하기에 딱이겠다 싶어 설정한 건데 허점이 있었다

그 이유는 아래 글에서 자세히 알 수 있다

 

Lombok and JPA: What Could Go Wrong? - DZone Java

 

간단하게 보자면 POJO로 만든 회원 엔티티가 있다고 할 때 

이 녀석의 식별자는 @GeneratedValue로 설정 되어있고 DB를 거쳐 온 게 아니라면 식별자 값이 없는 상태다

이 놈을 HashSet, HashMap 등 해시로 관리하는 컬렉션에 저장하고 DB에 저장한 후 조회하여 서로 비교해보면 

우리의 개념으로는 같은 엔티티라 인식 되지만 식별자 값이 다르기 때문에 다른 엔티티로 나온다

이런 문제가 어떻게 발생할 수 있을까 싶긴 한데 대규모로 갈수록 코드에 빈틈이 없어야 하기에 리뷰받은 내용대로 수정했다

 

그동안은 개발에 필요한 최소 지식만 갖추고 일단 만들어 재꼈는데 제대로 작성해보려니 

간단하다고 생각했던 부분도 깊게 파야되고 얽혀 있는 다른 놈도 봐야하고 성능도 신경 써야 하고.. 바쁘다 바빠

개인적으로 클린 코드 책을 굉장히 좋아하는데 특히 인상 깊게 남은 키워드가 있다

소프트웨어 장인 정신과 보이스카웃 규칙이다

클린 코드를 향해서 이유 있는 코드를 작성하고 우아한 코드를 만들도록 노력하자

커밋 푸시 전에 뒷정리도 꼭 하고 🔥