BookQueryDslRepository에 @Repository 애너테이션이 아니라 @Component 애너테이션을 사용하신 이유가 궁금합니다.

헉, 정신 없이 지내다가 답변이 달린 줄도 모르고 있었네요.예외 번역 때문이었군요. 감사합니다! 덕분에 의문이 좀 풀렸습니다.

프록시 관련한 equals()오버라이딩, 제가 이해한 것이 맞나요?

친절한 답변 감사드립니다. 덕분에 이해가 되었습니다. 다만, 관련해서, 추가적으로 궁금한 것들이 있습니다. 1. getter로 프록시의 필드에 접근하려고 하면 프록시의 getName() 메서드가 프록시 내부의 target.getName 메서드를 호출하는 방식으로 오버라이딩 되어 있어서, 3에 대한 답변처럼, 필드 접근방식과 다르게 원본 객체의 값을 받아올 수 있는 것일까요? (반면 필드 값의 경우 이 방식의 해결이 불가능하기에 null을 반환하는 것이고) 2. 현 강의의 범위에서는 약간 벗어나지만, getter/setter 메서드 자체에 대한 의문입니다. 자바빈 프로퍼티 규약 때문에 getter와 setter를 사용하는 것은 알겠습니다. 그런데 왜 getter와 setter를 사용하는가에 대해서는 약간 의문이 남아 있습니다. public으로 공개한 getter와 setter 메서드를 만드는 것은 결과적으로 필드 값 자체에 어디에서든 접근 가능하다는 면에서 클래스 자체의 은닉에는 의미가 없지 않나 하는 의문입니다. 그래서 제가 getter/setter 사용에 대해 생각하는 봐를 정리해 봤는데, 다음과 같습니다: 1) 필드접근과 다르게, getter/setter 접근은 오버라이드를 이용해서 상황에 맞출 수 있기 때문(제가 위의 1번 물음에서 하이버네이트가 getter를 해결할 때 사용한 방식이라고 생각한 것입니다.) 2) 변수 자체에 대한 접근을 통제할 수 있는 필드 접근 제한자에 비해, 불변객체 등을 만들 때처럼 getter만 만들고 setter는 만들지 않는 식으로 읽기/쓰기 중 하나만 제약할 수 있어서(물론 컬렉션의 경우에는 변경 가능성이 남아 있지만) 3) getter/setter라는 명명이 개발에서 가장 자주 쓰이는 필드 변수에 대한 읽기/쓰기 변수의 명명법 상 일관성을 줘서 3)의 경우에는 의문점이 있는데, 그렇다면 IntelliJ 단축키로 만들어지는 것과 같은 기본적인 getter/setter 이상으로 추가적인 무언가가 있거나, 변화되었다면 getter/setter 명명법을 사용하지 않는 편이 나을까요? 4) getter는 side effect에 대해 안전하지만, setter는 그렇지 않기 때문에, setter 사용은 가급적 피하는 것이 좋다. 3. Hibernate.unproxy()메서드 공부하다가 Hibernate.unproxy()의 존재에 대해 알게 되었는데요. 참고한 글 링크, 글에 대한 간단 번역 위 글에서는 프록시로 로딩된 객체와 원본 객체의 동등성 문제를 unproxy를 이용해서 해결하던데, 이런 방법이 많이 쓰이는지도, 동등성 문제라면 equals() hashCode()오버라이딩 하는 것에 비해, 굳이 이 방법을 쓸 메리트가 있는지도 의문이 들었습니다. 하이버네이트에 종속적이기도 하구요. 동등성 비교 외에 프록시 객체로 인해 문제 발생할 이유가 더 있을까요? unproxy + 형변환 조합이 존재하는 것에는 분명 이유가 있을 것 같은데, 굳이 .class()를 맞춰주는 방식이 필요한 상황이 있을까요?