모든 객체의 공통 메서드
-
equals 는 일반 규약을 지켜 재정의하라.
-
꼭 필요한 경우가 아니면 equals를 재정의하지 말자. 많은 경우에 Object의 equals가 여러분이 원하는 비교를 정확히 수행해 준다. 재정의해야 할때는 그 클래스의 핵심 필드 모두를 빠짐없이, 다섯 가지 규약을 확실히 지켜가며 비교해야 한다.
-
-
equals를 재정의하려거든 hashCode도 재정의하라.
-
equals를 재정의할 때는 hashCode도 반드시 재정의해야 한다. 그렇지 않으면 프로그램ㅁ이 제대로 동작하지 않을 것이다. 재정의한 hashCode는 Object의 API 문서에 기술된 일반 규약을 따라야 하며, 서로 다른 인스턴스라면 되도록 해시코드도 서로 다르게 구현해야 한다.이렇게 구현하기가 어렵지는 않지만 조금 따분한 일이긴 하다. 하지만 걱정마시라. 아이템 10에서 이야기한 AutoValue 프레임워크를 사용하면 멋진 equals와 hashCode를 자동으로 만들어준다, IDE들도 이런 기능을 일부 제공한다.
-
-
toString을 항상 재정의하라.
-
모든 구체 클래스에서 Object의 toString을 재정의하자. 상위 클래스에서 이미 알맞게 재정의한 경우는 예외다. toStringㅇ을 재정의한 클래스는 사용하기도 즐겁고 그 클래스를 사용한 시스템을 디버깅하기 쉽게 해준다. toString은 해당 객체에 관한 명확하고 유용한 정보를 읽기 좋은 형태로 반환해야 한다.
-
-
clone 재정의는 주의해서 진행하라.
-
Cloneable이 몰고 온 모든 문제를 되짚어 봤을때, 새로운 인터페이스를 만들 때는 절대Cloneable을 확장해서는 안되며, 새로운 클래스도 이를 구현해서는 안된다. final클래스라면 Cloneable을 구현해도 위험이 크지 않지만, 성능 최적화 관점에서 검토한 후 별다른 문제가 없을 때만 드물게 허용해야 한다. 기본 원칙은 '복제 기능은 생성자와 팩토리를 이용한게 최고' 라는 것이다. 단, 배열만은 Clone메서드 방식이 가장 깔끔한, 이 규칙의 합당한 예외라 할수 있다.
-
-
Comparable을 구현할지 고려하라.
-
순서를 고려해야 하는 값 클래스를 작성한다면 꼭 Comparable 인터페이스를 구현하여, 그 인스턴스들을 쉽게 정렬하고, 검색하고, 비교 기능을 제공하는 컬렉션과 어울러지도록 해야 한다. compareTo 메서드에서 필드의 값을 비교할 때 < 와 > 연산자는 쓰지 말아야 한다. 그 대신 박싱된 기본 타입 클래스가 제공하는 정적 compare메서드나 Comparator인터페이스가 제공하는 비교자 생성 메서드를 사용하자
-
참조서적 : 이펙티브 자바 Effective Java 3/E (http://www.yes24.com/Product/Goods/65551284)
'백엔드 > Java' 카테고리의 다른 글
Effective Java 맛보기 6탄 (0) | 2019.09.20 |
---|---|
Effective Java 맛보기 5탄 (0) | 2019.09.17 |
Effective Java 맛보기 4탄 (0) | 2019.09.16 |
Effective Java 맛보기 3탄 (0) | 2019.09.15 |
Effective Java 맛보기 1탄 (0) | 2019.09.14 |
Spring Data Redis - Jedis vs Lettuce (0) | 2019.08.18 |
리팩토링 맛보기 1탄 (0) | 2019.08.11 |
JUnit 4.5 에러 (0) | 2019.03.13 |
댓글