[이펙티브 자바] 3장 : 모든 객체의 공통 메서드

모든 객체의 공통 메서드

Object는 객체를 만들 수 있는 구체 클래스지만 기본적으로 상속해서 사용하도록 설계됨

Object에서 final이 아닌 메서드는 모두 재정의를 염두에 두고 설계되어짐. 

따라서, 이 메서드를 올바르게 오버라이딩해야만 클래스가 오동작 하지 않는다.

아이템 10 : equals는 일반 규약을 지켜 재정의하라

equals 메서드는 오버라이딩 하지 않으면 오직! 자기자신만 같다. (객체식별성으로 비교)

 

• 오버라이딩이 필요한 경우
  • 객체 식별이 아닌 '논리적 동치성'을 확인 해야할 때
    • 주로 값 클래스 ( new Inteager(2)를 두번하면 물리적으로 다른 객체이나 논리적으로는 같은 값을 가지는 객체가 된다

양질의 equals 메서드 구현방법

1. == 연산자를 사용해 입력이 자기 자신의 참조인지 확인한다. (자기자신이면 true반환)

2. instanceof 연산자로 입력이 올바른 타입인 지 확인한다. 

3. 입력을 올바른 타입으로 형변환한다. -> 2번과정으로 인해 무조건 형변환 성공

4. 입력 객체와 대응되는 자기자신의 '핵심' 필드들이 모두 일치하는지 하나씩 검사한다. 모든 필드가 일치하면 true, 아니면 false 반환

 

# 위의 비법을 적용한 equals 메서드 구현 코드 #

// 코드 10-6 전형적인 equals 메서드의 예 (64쪽)
public final class PhoneNumber {
    private final short areaCode, prefix, lineNum;

    public PhoneNumber(int areaCode, int prefix, int lineNum) {
        this.areaCode = rangeCheck(areaCode, 999, "지역코드");
        this.prefix   = rangeCheck(prefix,   999, "프리픽스");
        this.lineNum  = rangeCheck(lineNum, 9999, "가입자 번호");
    }

    private static short rangeCheck(int val, int max, String arg) {
        if (val < 0 || val > max)
            throw new IllegalArgumentException(arg + ": " + val);
        return (short) val;
    }

    @Override public boolean equals(Object o) {
        if (o == this)
            return true;
        if (!(o instanceof PhoneNumber))
            return false;
        PhoneNumber pn = (PhoneNumber)o;
        return pn.lineNum == lineNum && pn.prefix == prefix
                && pn.areaCode == areaCode;
    }

    // 나머지 코드는 생략 - hashCode 메서드는 꼭 필요하다(아이템 11)!
}

 

마지막으로 equals를 재정의할 땐 hascode도 반드시 재정의하자.

 

"핵심정리"

꼭 필요한 경우가 아니면 equals를 재정의하지말고 필요한 경우 클래스의 핵심 필드를 빠짐없이 위 핵심규약을 지켜가며 비교하자

 

아이템 11 : equals를 재정의하려거든 hasecode도 재정의하라

hasecode를 재정의하지 않으면 HashMap이나 HashSet같은 컬렉션의 원소로 사용할 때 문제가 발생한다.

• 논리적으로 같은 객체는 같은 해시코드를 반환해야한다. (하지만 재정의하지 않으면 다른 해시코드를 반환할 수 있는 문제 발생)

논리적으로 같다는 것은 아이템10번의 조건을 만족하고 모든 필드가 같다는 것이다. 하지만 hasecode는 인스턴스마다 다르게 부여되므로 논리적으로 같아도 다른 객체로 인식이 될 수 있다.

 

따라서, hascode메서드를 핵심 필드를 이용하여 hasecode를 만드는 방식으로 개선하자. 이렇게 되면 논리적으로 동치인 객체는 같은 hasecode를 가질 수 있게 된다.

    @Override 
    public int hashCode() {
        int result = Short.hashCode(areaCode);
        result = 31 * result + Short.hashCode(prefix);
        result = 31 * result + Short.hashCode(lineNum);
        return result;
    }

아이템 12 : toString을 항상 재정의하라

toString의 규약은 "모든 하위 클래스에서 이 메서드를 재정의하라" 이다. toString은 단지 클래스이름@해시코드를 보여줄 뿐 별 의미가 없다.

우리는 이 메서드를 오버라이드 하여 사람이 읽기 쉬운 유익한 정보로 바꿔줘야한다.

 

toString()을 잘 구현해두면 사용하기 편하고 디버깅에 많은 도움이 된다.

 

구현시 사용할 포멧을 주석으로 명시하거나 예시를 들어서 설명해둘 수 있다. 클래스의 주요 정보를 모든 표현하는 것이 좋다.

 

상위 클래스에 이미 알맞게 정의했다면 그대로 가져다 써도 된다.

 

아이템 13 : clone 재정의는 주의해서 진행해라

메서드 하나 없는 Cloneable 인터페잇느는 Object의 protected 메서드인 clone의 동작 방식을 결정한다.

(여기서는 이례적으로 메서드의 동작 방식 변경으로 인터페이스를 사용했다)

 

Cloneable을 구현한 클래스는 clone메서드를 public으로 제공하게 되고 clone을 통해 복제가 제대로 될 거라 기대한다.

하지만, 해당클래스나 상위 클래스들이 생성자를 호출하지 않고도 객체를 생성하는 것이 가능할까??

 

클래스가 불변인 경우에는 clone이 가능할 수 있지만 클래스 내부에 참조객체 같은 것이 있다면 복사한 객체가 똑같은 객체를 가르키지 않도록 객체를 새로 생성하거나 해줘야한다.

어쩔 수 없이 cloneable을 구현한 클래스를 확장한다면 clone을 잘 작동하도록 구현해야만 한다.

 

하지만, 그렇지 않은 상황(cloneable을 구현하지 않아도 되는 상황)에서는 '복사 생성자'와 '복사 팩터리'라는 더 나은 객체 복사 방식을 제공할 수 있다.

public Yum(Yum yum) {...}; // 자기 자신과 같은 클래스의 인스턴스를 인수로 받는 생성자
public static Yum newInstance(Yum yum) {...}; // 복사 생성자를 모방한 정적 팩터리

이 두 가지 방식은 생성자를 사용하지 않는 위험한 객체 생성 메커니즘을 사용하지 않는다.

 

"핵심 정리"

새로운 인터페이스 작성 시 절대 Cloneable 확장하지 말고, 새로운 클래스도 이를 구현하지 말자.

복제 기능은 생성자와 팩터리를 이용하는 것이 최고다. (배열은 예외)

 

아이템 14 : Comparable을 구현할지 고려하라

compareTo는 Object의 메서드가 아니다. 이 메서드는 단순 동치성 비교에 더해 순서까지 비교할 수 있다.

이를 통해 Comparable을 구현한 클래스는 Arrays.sort(); 처럼 손쉽게 정렬이 가능하다.

• Comparable을 구현하면 이 인터페이스를 활용하는 많은 알고리즘과 컬렉션을 사용할 수 있다.
• 알파벳, 숫자, 연대와 같이 순서가 명확한 값 클래스를 작성한다면 반드시 구현하자
• Comparable을 구현하지 않은 필드나 표준이 아닌 순서로 비교해야 한다면 Comparator를 대신 사용한다.

제네릭 인터페이스이므로 compareTo의 메서드의 인수 타입은 컴파일 타입에 정해진다.

public final class CaseInsensetiveString implements Comparable<CaseInsensitiveString> {
  	public int compareTo(CaseInsensitiveString cis) {
      	return String.CASE_INSENSITIVE_ORDER.compare(s. cis.s);
    }
}

 

클래스에 핵심 필드가 여러 개인 경우 가장 핵심적인 필드부터 비교하자. 비교 결과가 0이 아니라면 즉, 순서가 결정되었다면 즉시 반환하면 된다. 아니라면 이후 필드에서 계속 비교를 진행해 나간다.

public int compareTo(PhoneNumber pn) {
  	int result = Short.compare(areaCode, pn.areaCode);
  	if (result == 0) {
      	result = Short.compare(prefix, pn.prefix);
      	if (result == 0) {
          	result = Short.compare(linenum, pn.lineNum);
        }
    }
		return result;
}

 

자바 8에서 추가된 비교자 생성 메서드를 이용하여 구현할 수 도 있다. 코드가 간결해진다.

// 코드 14-3 비교자 생성 메서드를 활용한 비교자 (92쪽)
    private static final Comparator<PhoneNumber> COMPARATOR =
            comparingInt((PhoneNumber pn) -> pn.areaCode)
                    .thenComparingInt(pn -> pn.prefix)
                    .thenComparingInt(pn -> pn.lineNum);

    public int compareTo(PhoneNumber pn) {
        return COMPARATOR.compare(this, pn);
    }

 

이따금 '값의 차'를 기준으로 음수와 0 그리고 양수의 값을 반환하는 CompareTo 메서드를 마주할 수 있다.

이 방식은 정수 오버플로우나 부동소수점 계산 방식에 오류를 발생시킬 수 있으므로 사용하면 안된다.

따라서 아래의 방법을 사용하자.

static Comparator<Object> hasCodeOrder = new Comparator<>() {
	public int compare(Object o1, Object o2) {
    	return Integer.compare(o1.haseCode(), o2.haseCode());
    }
}