[Effective Java] Chapter 3: 모든 객체의 공통 메서드

Item10. equals는 일반 규약을 지켜 재정의하라

• 필요한 경우가 아니라면 equals를 재정의 하지말자.
• 많은 경우에 Object의 equals가 우리가 원하는 비교를 정확히 수행해준다.
• 재정의해야 할 때는 그 클래스의 핵심필드 모두를 빠짐없이 5가지 규약을 지켜가며 비교해야한다.
• equals의 5가지 규약 : 반사성, 대칭성, 추이성, 일관성, null-아님
• Link : https://jyami.tistory.com/66

item10. equals는 일반 규약을 지켜 재 정의하라

 

 

Item11. equals를 재정의하려거든 hashCode도 재정의하라

• equals를 재정의할 때는 hashCode도 반드시 재정의해야 한다. (프로그램이 제대로 동작해야하므로)
• 재정의한 hashCode는 Object의 API 문서에 기술된 일반 규약을 따라야한다.
• 3번에 써둔 좋은 HashCode를 작성하는 방법을 참고하자
• 서로 다른 인스턴스라면 되도록 해시코드도 서로 다르게 구현해야한다.
• AutoValue 프레임워크를 사용하면 멋진 equals와 hashCode를 자동으로 만들어준다.
• Link : https://jyami.tistory.com/67

Item11. equals를 재정의하려거든 hashCode도 재정의하라

 

Item12. toString을 항상 재정의하라

• 모든 구체 클래스에서 Object의 toString을 재정의하자.
• 상위 클래스에서 이미 알맞게 재정의한 경우에는 예외다.
• toString을 재정의한 클래스는 사용하기도 즐겁고 그 클래스를 사용한 시스템 디버깅에 용이하다.
• toString은 해당 객체에 관한 명확하고 유용한 정보를 읽기 좋게 반환해야한다.
• Link : https://jyami.tistory.com/68

Item12. toString을 항상 재정의하라

 

Item13. clone 재정의는 주의해서 진행하라

• Cloneable이 몰고 온 모든 문제를 되짚어봤을 때, 새로운 인터페이스를 만들 때는 절대 Cloneable을 확장해서는 안되며, 새로운 클래스도 이를 구현해서는 안된다.
• final 클래스라면 Clonealbe을 구현해도 위험이 크지 않지만, 성능 최적화 관점에서 검토후 별다른 문제가 없을 대만 드물게 허용하자
• 기본 원칙은 '복제 기능은 생성자와 팩터리를 이용하는게 최고'라는 것이다.
• 단, 배열만은 clone 메서드 방식이 가장 깔끔한, 이 규칙의 합당한 예외라 할 수 있다.
• Link : https://jyami.tistory.com/69

item13. clone 재정의는 주의해서 진행하라

 

Item14. Comparable을 구현할지 고려하라

• 순서를 고려해야하는 값 클래스를 작성한다면 꼭 Comparable 인터페이스를 구현하여, 그 인스턴스들을 쉽게 정렬하고, 검색하고, 비교 기능을 제공하는 컬렉션과 어우러지도록 해야 한다.
• compareTo 메서드에서 필드의 값을 비교할 때 < 와 > 연산자는 쓰지 말자.
• 그대신 박싱된 기본 타입 클래스가 제공하는 정적 compare 메서드나, Comparator 인터페이스가 제공하는 비교자 생성 메서드를 사용하자
• Link : https://jyami.tistory.com/70

Item 14. Comparable을 구현할지 고려하라