[Effective Java 3/E] 3장 모든 객체의 공통 메서드

📋 목차.

1. 챕터
    .아이템 10 - equals는 일반 규약을 지켜 재정의 하라
    .아이템 11 - equals를 재정의하려거든 hashCode도 재정의하라
    .아이템 12 - toString을 항상 재정의하라
    .아이템 13 - clone 재정의는 주의해서 진행하라
    .아이템 14 - Comparable을 구현할지 고려하라.

---

✔️ 내용.

 

3. 모든 객체의 공통 메서드

 

 Object는 객체를 만들 수 있는 구체 클래스이지만. 기본적으로는 상속해서 사용하도록 설계되었다.
Object에서final이 아닌 메서드(equals, hashCode, toString, clone, finalize)는 모두 재정의를 염두에 두고 설계된 것이라 재정의 시 지켜야 하는 일반 규약이 명확히 정의되어 있다.

 이번 장에서는 final이 아닌 Object 메서드들을 언제 어떻게 재정의해야 하는지를 다룬다.
 
 - final 은 2장 Item 8에서 다뤘으므로 언급하지 않는다.
 - Comparable.compareTo의 경우 Object의 메서드는 아니지만 이 비슷하여 이번 장에서 같이 다룬다.

---

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

 

 equals 메서드는 재정의하기 쉬워 보이지만 곳곳에 함정이 도사리고 있다.

다음 열거 상황 중 한가지라도 해당한다면 재정의하지 않는 것이 좋다.

 

1. 각 인스턴스가 본질적으로 고유하다.

 - 값을 표현하는 게 아니라 동작하는 개체를 표현하는 클래스

 - Thread가 좋은 예로, Object의 equals 메서드는 이러한 클래스에 딱 맞게 구현되어 있다.

 

2. 인스턴스의 '논리적 동치성'을 검사할 일이 없다.

 - 클라이언트가 논리적 동치성을 원하지 않거나 애초에 필요하지 않다고 판단할 경우 Object의 기본 equals로만 해결한다.

 

3. 상위 클래스에서 재정의한 equals가 하위 클래스에도 딱 들어맞는다.

 - 예로 대부분의 Set 구현체는 AbstractSet이 구현한 equals를 상속받아 쓰고, List 구현체들은 AbstractList로부터, Map 구현체들은 AbstractMap으로부터 상속받아 그대로 쓴다.

 

4. 클래스가 private이거나 package-private(default)이고 equals  메서드를 호출할 일이 없다.

 - 호출할 일이 없고 혹여나 실수로라도 equals를 호출하지 못하게 막고 싶다면 다음과 같이 구현해 두자

public class NonEquals {
    @Override
    public boolean equals(Object obj) {
        throw new AssertionError();
    }
}

 

 그렇다면 equals를 재정의해야 할 때는 언제인가?

 

- 객체 식별성(두 객체가 물리적으로 같은가)이 아니라 논리적 동치성을 확인해야 하는데, 상위 클래스의 equals가 논리적 동치성을 비교하도록 재정의 되지 않았을 때이다. 주로 Integer와 String처럼 값을 표현하는 클래스이다. 두 값 객체를 equals로 비교하는 프로그래머는 객체가 같은지가 아니라 값이 같은지 알고 싶어 할 것이다.

 

 값 클래스여도 인스턴스가 둘 이상 만들어지지 않음을 보장하는 인스턴스 통제 클래스(아이템 1)라면 equals를 재정의하지 않아도 된다. Enum(아이템 34)도 여기에 해당한다. 이런 클래스에서는 어차피 논리적으로 같은 인스턴스가 2개 이상 만들어지지 않으니 논리적 동치성과 객체 식별성이 사실상 똑같은 의미가 된다. 따라서 Object의 equals가 논리적 동치성까지 확인해 준다고 볼 수 있다.

 

 equals 메서드를 재정의 할 때는 반드시 일반 규약을 따라야 한다. 다음은 object 명세에 적힌 규약이다.

 equals 메서드는 동치관계를 구현하며, 다음을 만족한다.

- 반사성(reflexivity) : null이 아닌 모든 참조 값 x에 대해, x.equals(x)는 true다.
- 대칭성(symmetry) : null이 아닌 모든 참조 값 x,y에 대해, x.equals(y) 가 true이면 y.equals(x)도 true 다.
- 추이성(transitivity) : null이 아닌 모든 참조 값 x,y,z에 대해, xequals(y)가 true이고 y.equals(z)도 true면 x.equals(z)도 true다.
- 일관성(consistency) : null이 아닌 모든 참조값 x,y에 대해, x.equals(y)를 반복해서 호출하면 항상 true를 반환하거나 항상 false를 반환한다.
- null-아님 : null이 아닌 모든 참조 값 x에 대해, x.equals(null)은 false 다.

 

 

 모든 객체 지향 언어의 동치 관계에서 발생하는 근본적인 문제가 있다.

- 구체 클래스를 확장해 새로운 값을 추가하면서 equals 규약을 만족시킬 방법은 존재하지 않는다. 객체 지향적 추상화의 이점을 포기하지 않는 한은 말이다.

 이 말은 얼핏, equals안의 instanceof 검사를 getClass 검사로 바꾸면 규약도 지키고 값도 추가하면서 구체 클래스를 상속할 수 있다는 뜻으로 들린다.

 

 - 리스코프 치환 원칙 위배

public class Point {

    final int x;
    final int y;

    public Point(int x, int y) {
        this.x = x;
        this.y = y;
    }

    @Override
    public boolean equals(Object obj) {
        if(!(obj instanceof Point))
            return false;
        Point p = (Point) obj;
        return p.x == x && p.y == y;
    }
}

public class CounterPoint extends Point {

    public CounterPoint(int x, int y) {
        super(x, y);
    }

    @Override
    public boolean equals(Object obj) {
    	// 리스코프 치환 원칙 위배
        if (obj == null || obj.getClass() != getClass())
            return false;
        Point p = (Point) obj;
        return p.x == x && p.y == y;
    }
}

 

 구체 클래스의 하위 클래스에서 값을 추가할 방법은 없지만 괜찮은 우회 방법이 있다. '상속 대신 컴포지션을 사용하라'는 아이템 18의 조언을 따르면 된다.

 Point를 상속하는 대신 Point를 CounterPoint의 private 필드로 두고, CounterPoint와 같은 위치의 일반 Point를 반환하는 뷰(view) 메서드(아이템 6)를 public으로 추가하는 식이다.

 

 - equals 규약을 지키며 값 추가

 

public class CounterPoint {

    private final Point point;
    private final int x;
    private final int y;
    public CounterPoint(int x, int y) {
        this.x = x;
        this.y = y;
        point = new Point(x, y);
    }

    /**
     * Point 뷰 반환
     */
    public Point asPoint(){
        return point;
    }
    
    @Override
    public boolean equals(Object obj) {
        if(!(obj instanceof CounterPoint))
            return false;
        CounterPoint cp = (CounterPoint) obj;
        return cp.point.equals(point);
    }
}

 

 클래스가 불변이든 가변이든 equals 판단에 신뢰할 수 없는 자원이 끼어들게 해서는 안된다.

예로 java.net.URL의 equals는 주어진 URL과 매핑된 호스트의 IP 주소를 이용해 비교한다. 호스트 이름을 IP 주소로 바꾸려면 네트워크를 통해야 하는데, 그 결과가 항상 같다고 보장할 수 없다. 이는 URL의 equals가 일반 규약을 어기게 하고, 실무에서도 종종 문제를 일으킨다.

 

    public boolean equals(Object var1) {
        if (!(var1 instanceof URL)) {
            return false;
        } else {
            URL var2 = (URL)var1;
            return this.handler.equals(this, var2); // 문제점
        }
    }
    
    // 문제점
    protected boolean equals(URL var1, URL var2) {
        String var3 = var1.getRef();
        String var4 = var2.getRef();
        return (var3 == var4 || var3 != null && var3.equals(var4)) && this.sameFile(var1, var2);
    }

 이런 문제를 피하려면 equals는 항시 메모리에 존재하는 객체만을 사용한 결정적 계산만 수행해야 한다.

 

 마지막 요건은 공식 이름이 없으므로 'null-아님'으로 부른다.

이름처럼 모든 객체가 null과 같지 않아야 한다. 명시적 null 검사는 필요 없다.

    @Override
    public boolean equals(Object obj) {
        // 필요 없다.
        if(obj == null)
            return false;
        return super.equals(obj);
    }

 

 - 묵시적 Null 검사로 instanceof 연산자로 올바른 타입인지 검사하자.

 

    @Override
    public boolean equals(Object obj) {
        // 묵시적 Null 검사
         if(!(obj instanceof MyType))
             return false;
         MyType myType = (MyType) obj;
        return super.equals(myType);
    }

 

 지금까지를 종합해서 양질의 equals 메서드 구현 방법을 단계별로 정리하면 다음과 같다.

 

1. == 연산자를 사용해 입력이 자기 자신의 참조인지 확인한다.

 - 자기 자신이면 true를 반환하여. 단순한 성능 최적화용으로, 비교 작업이 복잡한 상황일 때 값어치를 한다.

 

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

 - 그렇지 않다면 false를 반환한다. 이때의 올바른 타입은 equals가 정의된 클래스인 것이 보통이지만, 가끔 그 클래스가 구현한 특정 인터페이스가 될 수 또 있다. 어떤 인터페이스는 자신을 구현한 (서로 다른) 클래스끼리 비교할 수 있도록 equals 규약을 수정하기도 한다. 이런 인터페이스를 구현한 클래스라면 equals에서 (클래스가 아닌) 해당 인터페이스를 사용해야 한다. Set, List, Map, Map.Entry 등의 컬렉션 인터페이스들이 여기에 해당한다.

 

	public boolean equals(Object o) {
            if (!(o instanceof Map.Entry)) {
                return false;
            } else {
                Map.Entry<?, ?> e = (Map.Entry)o;
                // 다른 구현체 확인
                return AbstractMap.eq(this.key, e.getKey()) && AbstractMap.eq(this.value, e.getValue());
            }
        }

 

3. 입력을 올바른 타입으로 형변환한다.

 - 앞선 2번에서 instanceof 검사를 했기 때문에 이 단계는 100% 성공한다.

 

4. 입력 객체와 자기 자신의 대응되는 '핵심'필드들이 모두 일치하는지 하니씩 검사한다.

 - 모든 필드가 일치하면 true, 하나라도 다르면 false를 반환한다. 2단계에서 인터페이스를 사용했다면 입력의 필드 값을 가져올 때도 그 인터페이스의 메서드를 사용해야 한다. 타입이 클래스라면 (접근 권한에 따라) 해당 필드에 직접 접근할 수도 있다.

 

 어떤 필드를 먼저 비교하느냐가 equals의 성능을 좌우하기도 한다. 최상의 성능을 바란다면 다를 가능성이 더 크거나 비교하는 비용이 싼 필드를 비교하자. 동기화용 락(lock) 필드 같이 객체의 논리적 상태와 관련 없는 필드는 비교하면 안 된다.

 

 equals를 다 구현했다면 세 가지만 자문해 보자. 대칭적인가? 추이성이 있는가? 일관적인가? 

 - 자문에서 끝내지 말고 단위 테스트를 작성해 돌려보자. 단, equals 메서드를 AutoValue(Google 프레임워크, 다른 예로 Lombok)를 이용해 작성했다면 테스트를 생략해도 안심할 수 있다. 물론 나머지 요건인 반사성과 null-아님도 만족해야 하지만, 이 둘이 문제 되는 경우는 별로 없다.

 

public 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;
    }
}

 

 마지막 주의 사항

 

1. equals를 재정의 할 땐 hashCode도 반드시 재정의하자(아이템 11)

2. 너무 복잡하게 해결하려 들지 말자.

 - 필드들의 동치성만 검사해도 equals 규약을 어렵지 않게 지킬 수 있다. 

3. Object 외의 타입을 매개변수로 받는 equals 메서드는 선언하지 말자.

 - 많은 프로그래머가 equals를 다음과 같이 작성해 놓고 문제의 원인을 찾아 헤맨다.

 

    // 입력 타입은 반드시 Object여야 한다., 컴파일 되지 않는다.
    @Override
    public boolean equals(MyClass obj) {
    }

 

핵심 정리

 꼭 필요한 경우가 아니면 equals를 재정의하지 말자. 많은 경우에 Object의 equals가 여러분이 원하는 비교를 정확히 수행해 준다. 재정의해야 할 때는 그 클래스의 핵심 필드 모두를 빠짐없이, 다섯 가지 규약을 확실히 지켜가며 비교해야 한다.

---

 

.아이템 11 - equals를 재정의하려거든 hashCode도 재정의하라

 

 equals를 재정의한 클래스 모두에서 hashCode도 재정의해야 한다.

- 그렇지 않으면 hashCode 일반 규약을 어기게 되어 해당 클래스의 인스턴스를 HashMap이나 HashSet 같은 컬렉션의 원소로 사용할 때 문제를 일으킨다. 다음은 Object 명세에서 발췌한 규약이다.

 

 - equals 비교에 사용되는 정보가 변경되지 않았다면, 애플리케이션 실행되는 동안 그 객체의 hashCode 메서드는 몇 번을 호출해도 일관된 값을 반환해야 한다. 단, 애플리케이션이 재실행되면 달라져도 상관없다.

 - equals(Object)가 두 객체를 같다고 판단했다면, 두 객체의 hashCode는 똑같은 값을 반환해야 한다.

 - equals(Object)가 두 객체를 다르다고 판단했더라도, 두 객체의 hashCode가 서로 다른 값을 반환할 필요는 없다. 단, 다른 객체에 대해서는 다른 값을 반환해야 해시테이블의 성능이 좋아진다.

 

 hashCode 재정의를 잘못했을 때 크게 문제가 되는 조항이 두 번째이다. 논리적으로 같은 객체는 같은 hashCode를 반환해야 한다.

 

        Map<PhoneNumber, String> m = new HashMap<>();
        // 1
        m.put(new PhoneNumber(707, 867, 5309), "제니");
        
        // 2
        m.get(new PhoneNumber(707, 867, 5309))

 위의 코드에서 1을 실행한 후 2를 실행하면 "제니"가 나오길 기대하지만 null 값이 나오게 된다.

PhoneNumber 클래스에서 hashCode를 재정의 하지 않았기 때문에 논리적 동치인 두 객체가 서로 다른 hashCode를 반환하여 두 번째 규약을 지키지 못했다.

 

 아래와 같이 PhoneNumber 클래스 안에 equals와 hashCode를 구현해 주면 기대한 값을 받을 수 있다.

public class PhoneNumber {
    private final int areaCode;
    private final int prefix;
    private final int lineNum;

    public PhoneNumber(int areaCode, int prefix, int lineNum) {
        this.areaCode = areaCode;
        this.prefix = prefix;
        this.lineNum = lineNum;
    }
    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;
        PhoneNumber that = (PhoneNumber) o;
        return areaCode == that.areaCode && prefix == that.prefix && lineNum == that.lineNum;
    }

    @Override
    public int hashCode() {
        return Objects.hash(areaCode, prefix, lineNum);
    }

}

 

 해시 충돌이 더욱 적은 방법을 써야 한다면 구아바의 com.google.common.hash.Hashing을 참고하자

 

 

 클래스가 불변이고 hashCode를 계산하는 비용이 크다면, 매번 새로 계산하기보다는 캐싱하는 방식을 고려해야 한다.

이 타입의 객체가 주로 해시의 키로 사용될 것 같다면 인스턴스가 만들어질 때 해시코드를 계산해 둔다.

 해시 키로 사용되지 않는 경우라면 hashCode가 처음 불릴 때 계산하는 지연 초기화 전략을 사용하면 어떨까? 이러한 지연 초기화 전략을 사용하려면 클래스의 스레드를 안전하게 만들도록 신경 써야 한다(아이템 83)

 

 예시는 다음과 같다

 

    private int hashCode; // 자동으로 0으로 초기화
    public int hashCode2() {
        int result = hashCode;
        if(result == 0) {
            Integer.hashCode(areaCode);
            result = 31 * result + Integer.hashCode(prefix);
            result = 31 * result + Integer.hashCode(lineNum);
            hashCode = result;
        }
        return result;
    }

 

 성능을 높이기 위해 hashCode 계산에서 핵심 필드를 생략해서는 안 된다.

- 속도야 빨라지지만, hash 품질이 저하되어 hashTable의 성능을 심각하게 떨어뜨릴 수 있다.

 

 hashCode가 반환하는 값의 생성 규칙을 API 사용자에게 자세히 공표하지 말자. 그래야 클라이언트가 이 값에 의지하지 않게 되고, 추후에 계산 방식을 바꿀 수도 있다.

 

 

핵심 정리

 equals를 재정의할 때는 hashCode도 반드시 재정의해야 한다. 그렇지 않으면 프로그램이 제대로 동작하지 않을 것이다. 재정의한 hashCode는 Object의 API 문서에 기술된 일반 규약을 따라야 한다.

---

 

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

 

 Object의 기본 toString 메서드는 우리가 작성한 클래스에 적합한 문자열을 반환하는 경우가 거의 없다. 이 메서드는 PhoneNumber@adbbd 처럼 단순히 '클래스_이름@16진수로표시한HashCode'를 반환할 뿐이다.

 toString의 일반 규약에 따르면 '간결하면서 사람이 읽기 쉬운 형태의 유익한 정보'를 반환해야 한다. 또한 '모든 하위 클래스에서 이 메서드를 재정의하라' 라고 규약 되어있다.

 toString이 앞선 equals와 hashCode 만큼 중요하지는 않지만. toString을 잘 구현한 클래스는 사용하기에 훨씬 좋고, 디버깅 또한 쉽다. toString 메서드는 객체를 println, printf, 문자열 연결(+), assert 구문에 넘길 때, 혹은 디버거가 객체를 출력할 때 자동으로 불린다. 직접 호출하지 않아도 어디선가 쓰이게 된다.

 

 실전에서 toString은 객체가 가진 주요한 정보를 모두 반환하는 게 좋다.

 

 toString에 포맷을 명시하는 게 필수는 아니지만 의도는 명확히 밝혀야 한다.

 

    /**
     * 폰 번호를 문자열로 반환
     * PhoneNumber{areaCode=82, prefix=10, lineNum=1234}
     */
    @Override
    public String toString() {
        return "PhoneNumber{" +
                "areaCode=" + areaCode +
                ", prefix=" + prefix +
                ", lineNum=" + lineNum +
                '}';
    }

 

 포맷 명시 여부와 상관없이 toString이 반환한 값에 포함된 정보를 얻어올 수 있는 APi를 제공하자.

예로 PhoneNumber 클래슨느 각각 지역코드, 프리픽스, 가입자 번호용 접근자를 제공해야 한다. 그렇지 않으면 이 정보가 필요한 프로그래머는 toString의 반환값을 파싱 할 수밖에 없다.

 

 정적 유틸리티 클래스(아이템 4)는 toString을 제공할 이유가 없다.. 또한, 대부분의 열거 타입(아이템 34)도 자바가 이미 완벽한 toString을 제공하여 따로 재정의 하지 않아도 된다. 하지만 하위 클래스들이 공유해야 할 문자열 표현이 있는 추상 클래스라면 toString을 재정의 해줘야 한다. 예로 대다수의 컬렉션 구현체는 추상 컬렉션 클래스들의 toString 메서드를 상속해 쓴다.

 

 

 Object의 toString보다는 Lombok이나 AutoValue의 자동 생성 toString이라도 사용하자.

 

핵심 정리

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

---

 

.아이템 13 - clone 재정의는 주의해서 진행하라

 

 Cloneable은 복제해도 되는 클래스임을 명시하는 용도의 믹스인 인터페이스(mixin interface, 아이템 20)지만 Cloneable을 구현하는 것만으로는 외부 객체에서 clone 메서드를 호출할 수 없다. clone 메서드가 선언된 곳이 Cloneable이 아닌 Object이고, 그마저도 protected라서 이다.

 

package java.lang;

public interface Cloneable {
}

  메서드 하나 없는 Cloneable 인터페이스가 하는 일은 뭘까?

 - Object의 protected 메서드인 clone의 동작 방식을 결정한다.

    //Object Class clone()

    @HotSpotIntrinsicCandidate
    protected native Object clone() throws CloneNotSupportedException;

 - Clonable을 구현한 클래스의 인스턴스에서 clone을 호출하면 그 객체의 필드들을 하나하나 복사한 객체를 반환하며, 그렇지 않은 클래스의 인스턴스에서 호출하면 'CloneNotSupportedException'을 던진다. 

 

 실무에서 Cloneable을 구현한 클래스는 clone 메서드를 public으로 제공하며, 사용자는 당연히 복제가 제대로 이뤄지리라 기대한다. 

 

 clone 메서드의 일반 규약은 허술하다. 다음은 Object 명세이다.

 

 이 객체의 복사본을 생성해 반환한다. '복사'의 정확한 뜻은 그 객체를 구현한 클래스에 따라 다를 수 있다.

 1.x.clone() != x
 2.x.clone().getClass() == x.getClass()
 3.x.clone().equals(x) 

 관례상 위 메서드들은 참이지만, 필수는 아니므로 강제성이 없다.

 

 즉, clone 메서드가 super.clone이 아닌, 생성자를 호출해 얻은 인스턴스를 반환해도 컴파일러는 불평하지 않는다. 하지만 이 클래스의 하위 클래스에서 super.clone을 호출한다면 잘못된 클래스의 객체가 만들어져 결국 하위 클래스의 clone 메서드가 제대로 동작하지 않게 된다. 

public static void main(String[] args) throws CloneNotSupportedException {

        B b1 = new B();
        B b2 = new A();
        Object cloneB1 = b1.clone();
        Object cloneB2 = b2.clone(); 
        System.out.println(cloneB1.getClass()); // B
        System.out.println(cloneB2.getClass()); // A
        System.out.println(cloneB1.getClass() == cloneB2.getClass()); // false

    }

    static class B implements Cloneable {
        @Override
        protected Object clone() throws CloneNotSupportedException {
            return super.clone();
        }
    }

    static class A extends B implements Cloneable{
        @Override
        protected Object clone() throws CloneNotSupportedException {
            return super.clone();
        }
    }

 clone을 재정의한 클래스가 final이라면 걱정해야 할 하위 클래스가 없으니 이 관례는 무시해도 안전하다. 하지만 final 클래스의 clone 메서드가 super.clone을 호출하지 않는다면 Cloneable을 구현할 이유도 없다. Object의 clone 구현의 동작 방식에 기댈 필요가 없기 때문이다.

 

 모든 필드가 기본 타입이거나 불변 객체를 참조한다면 이 객체는 완벽히 우리가 원하는 상태라 더  손볼 곳이 없다.

쓸데없는 복사를 지양한다는 관점에서 보면 불변 클래슨느 굳이 clone 메서드를 제공하지 않는 게 좋다.

 

public class PhoneNumber implements Cloneable {

    private final short areaCode, prefix, lineNum;

    public PhoneNumber(short areaCode, short prefix, short lineNum) {
        this.areaCode = areaCode;
        this.prefix = prefix;
        this.lineNum = lineNum;
    }

    @Override
    public PhoneNumber clone() {
        try {
            return (PhoneNumber) super.clone();
        } catch (CloneNotSupportedException e) {
            throw new AssertionError(); // 모든 필드가 기본 타입이기 때문에 일어날 수 없는 일이다. or 불변객체의경우
        }
    }
}

 재정의한 메서드의 반환 타입은 상위 클래스의 메서드가 반환하는 하위 타입일 수 있다. 이 방식으로 클라이언트가 형변환 하지 않아도 되게끔 해주자. 이를 위해 앞 코드에서는 super.clone에서 얻은 객체를 반환하기 전에 PhoneNumber로 형변환하였다.

 

 super.clone을 try-catch로 감싼 이유는 Object의 clone 메서드가 검사 예외인 CloneNotSupportedExceptoin을 던지도록 선언되어있기 때문이다. 우리는 성공할 것임을 알고 있다. 사실은 비검사 예외였다는 신호다(아이템 71)

 

 다음은 가변 객체를 참조하는 순간이다.

public class Stack implements Cloneable{
    private Object[] elements;
    private int size = 0;
    private static final int DEFAULT_INITIAL_CAPACITY = 16;

    public Stack() {
        this.elements = new Object[DEFAULT_INITIAL_CAPACITY];
    }

    public void push(Object e){
        ensureCapacity();
        elements[size++] = e;
    }

    public Object pop(){
        if(size == 0)
            throw new EmptyStackException();
        Object result = elements[--size];
        elements[size] = null; // 다 쓴 참조 해제
        return result;
    }

    /**
     * 원소를 위한 공간을 적어도 하나 이상 확보한다.
     * 배열 크기를 늘려야 할 때마다 대략 두 배씩 늘린다.
     */
    private void ensureCapacity() {
        if (elements.length == size)
            elements = java.util.Arrays.copyOf(elements, 2 * size + 1);
    }

    @Override
    public Stack clone() {
        try {
            Stack result = (Stack) super.clone();
            result.elements = elements.clone();
            return result;
        } catch (CloneNotSupportedException e) {
            throw new AssertionError(); // 일어날 수 없는 일이다.
        }
    }
}

 만일 단순히 super.clone값을 아래와 같이 반환했다면?

    @Override
    public Stack clone() {
        try {
            Stack clone = (Stack) super.clone();
            // TODO: copy mutable state here, so the clone can't change the internals of the original
            return clone;
        } catch (CloneNotSupportedException e) {
            throw new AssertionError();
        }
    }

 - size 필드는 올바른 값을 갖지만, elements 필드는 원본 Stack 인스턴스와 똑같은 배열을 참조할 것이다. 원본이나 복제본 중 하나를 수정하면 다른 하나도 수정되어 불변식을 해치게 된다. 따라서 프로그램이 원하는 대로 동작하지 않게 된다.

 

 Stack 클래스의 하나뿐인 생성자를 호출하면 앞선 상황은 절대 일어나지 않는다. clone 메서드는 사실상 생성자와 같은 효과를 낸다. 즉 , clone은 원본 객체에 아무런 해를 끼치지 않는 동시에 복제된 객체의 불변식을 보장해야 한다.

그러기 위해 Stack의 clone 메서드는 제대로 동작하려면 스택 내부 정보를 복사해야 하는데, 가장 쉬운 방법으로 elements 배열의 clone을 재귀적으로 호출해 주는 것이다.

 

   @Override
    public Stack clone() {
        try {
            Stack result = (Stack) super.clone();
            result.elements = elements.clone();
            return result;
        } catch (CloneNotSupportedException e) {
            throw new AssertionError(); // 일어날 수 없는 일이다.
        }
    }

  위의 elements.clone() 에서 Object[]로 형변환할 필요는 없다. 배열의 clone은 런타임 타입과 컴파일타임 타입 모두가 원본 배열과 똑같은 배열을 반환한다. 따라서 배열을 복제할 때는 배열의 clone 메서드를 사용하라고 권장한다. 사실, 배열은 clone 기능을 제대로 사용하는 유일한 예라 할 수 있다.

 

 한편, elements 필드가 final이었다면 앞서의 방식은 작동하지 않는다. final 필드에는 새로운 값을 할당할 수 업식 때문이다. 이는 근본적인 문제로, 직렬화와 마찬가지로 Cloneable 아키텍처는 '가변 객체를 참조하는 필드는 final로 선언하라'는 일반 용법과 충돌한다.

 

 clone을 재귀적 호출하는 것만으로 충분하지 않을 때도 있다. 해시 테이블을 예로 보면 내부는 버킷들의 배열이고 버킷은key-value로 이루어진 엔트리이다. clone을 보면 다음과 같다.

 

public class Hashtable<K, V> extends Dictionary<K, V> implements Map<K, V>, Cloneable, Serializable {
    private transient Entry<?, ?>[] table;
    
    public synchronized Object clone() {
        Hashtable<?, ?> t = this.cloneHashtable();
        t.table = new Entry[this.table.length];

        for(int i = this.table.length; i-- > 0; t.table[i] = this.table[i] != null ? (Entry)this.table[i].clone() : null) {
        }

        t.keySet = null;
        t.entrySet = null;
        t.values = null;
        t.modCount = 0;
        return t;
    }
    
    private static class Entry<K, V> implements Map.Entry<K, V> {
        final int hash;
        final K key;
        V value;
        Entry<K, V> next;
    	protected Object clone() {
            return new Entry(this.hash, this.key, this.value, this.next == null ? null : (Entry)this.next.clone());
        }
    }
}

 

 앞선 stack 처럼 elements(HashTable의 table)을 복사하지 않고 순회하며 entry의 복사를 진행한다.

 

 생성자에서는 재정의될 수 있는 메서드를 호출하지 않아야 하는데(아이템 19) clone 메서드도 마찬가지다. 만약 clone이 하위 클래스에서 재정의한 메서드를 호출하면, 하위 클래스는 복제 과정에서 자신의 상태를 교정할 기회를 잃게 되어 원본가 복제본의 상태가 달라질 가능성이 크다. 

 

 Object의 clone 메서드는 CloneNotSupportedException을 던진다고 선언했지만 재정의한 메서드는 그렇지 않다. public인 clone 메서드에서는 throws 절을 없애야 한다. 검사 예외를 던지지 않아야 그 메서드를 사용하기 편하기 때문이다.(아이템 71)

 

 상속해서 쓰기 위한 클래스 설계 방식 두 가지(아이템 19) 중 어느 쪽에서든, 상속용 클래스는 Cloneable을 구현해서는 안 된다. Object의 방식을 모방할 수도 있다. 제대로 작동하는 clone 메서드를 구현해 protected로 두고 CloneNotSupportedException도 던질 수 있다고 선언하는 것이다. 그러므로 하위 클래스에서 clone을 재정의하지 못하게 한다.

 

        @Override
        protected final Object clone() throws CloneNotSupportedException {
            return new CloneNotSupportedException();
        }

 

 Cloneable을 구현한 스레드 안전 클래스를 작성할 때는 clone 메서드 역시 적절히 동기화해줘야 한다.(아이템 78)

Object의 clone메서드는 동기화를 신경 쓰지 않는다. 그러니 super.clone 호출 외에 다른 할 일이 없더라도 clone을 재정의하고 동기화해줘야 한다.

 

 Cloneable을 이미 구현한 클래스를 확장한다면 어쩔 수 없이 clone을 잘 작동하도록 구현해야 한다. 그렇지 않은 상황에서는 복사 생성자와 복사 팩터리로 더 나은 객체 복사 방식을 택한다.

    static class C {

        // 복사 생성자
        public C(C c) {
            // ...
        }

        // 복사 팩토리
        public static C newInstance(C c) {
            // ...
            return new C(c);
        }
    }

 

 복사 생성자, 복사 팩터리의 더 정확한 이름은 변환 생성자(conversion constructor)와 변환 팩토리(conversion factory)이다. 이들을 이용하면 클라이언트는 원본의 구현 타입에 얽매이지 않고 복제본의 타입을 직접 선택할 수 있다. 예로 HashSet의 객체 s를 TreeSet 타입으로 복제할 수 있다.

 

핵심 정리

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

---

 

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

 

public interface Comparable<T> {
    int compareTo(T var1);
}

 

 Comparable의 compareTo메서드는 는 단순 동치성 비교에 더해 순서까지 비교할 수 있으며 제네릭 하다.

Comparable을 구현했다는 것은 그 클래스의 인스턴스들에는 자연적인 순서가 있음을 뜻한다.

 

 자바 플랫폼 라이버리들의 모든 값 클래스와 열거 타입(아이템 34)이 Comparable을 구현했다. 알파벳, 숫자, 연대 같이 순서가 명확한 값 클래스를 작성한다면 반드시 Comparable 인터페이스를 구현하자.

 

 compareTo 메서드의 일반 규약은 다음과 같고 equals의 규약과 비슷하다.

 

이 객체와 주어진 객체의 순서를 비교한다. 이 객체가 주어진 객체보다 작을 경우 음의 정수, 같으면 0, 크면 양의 정수를 반환한다. 이 객체와 비교할 수 없는 타입의 객체가 주어지면 ClassCastException을 던진다.
 다음 설명에서 sgn(표현식) 표기는 수학에서 말하는 부호 함수(signum function)을 뜻하며, 표현식의 값이 음수, 0, 양수 일 때 -1,0,1을 반환하도록 정의했다.

 - Comparable을 구현한 클래스는 모든 x,y에 대해 sgn(x.compareTo(y)) == -sgn(y.compareTo(x))여야 한다. (예외 처리 역시 동일)
 - Comparable을 구현한 클래스는 추이성을 보장해야 한다. 즉, (x.compareTo(y) > 0 && y.compareTo(z) >0) 이면 x.compareTo(z) > 0이다.
 - Comparable을 구현한 클래스는 모든 z에 대해 x.compareTo(y) == 0 이면 sgn(x.compareTo(z) == sgn(y.compareTo(z)) 다.
 - 권고가 필수는 아니지만 꼭 지킬 사항이다. (x.compareTo(y) == 0) == (x.equals(y)) 여야 한다. Comparable을 구현하고 이 권고를 지키지 않는 모든 클래스는 그 사실을 명시해야 한다. 다음과 같이 명시하면 적당할 것이다. 
 *주의: 이클래스의 순서는 equals의 메서드와 일관되지 않다

 

 모든 객체에 대해 전역 동치관계를 부여하는 equals 메서드와 달리, compareTo는 타입이 다른 객체를 신경 쓰지 않아도 된다. 타입이 다른 객체가 주어지면 간단히 ClassCastException을 던져도 되며, 대부분 그렇게 한다. 물론 공통 인터페이스를 매개로 이뤄졌을 경우는 다른 타입 사이의 비교도 허용된다.

 hashCode 규약을 지키지 못하면 해시를 사용하는 클래스와 어울리지 못하듯,  compareTo 규약을 지키지 못하면 비교를 활용하는 클래스와 어울리지 못한다. 예로 TreeSet과 TreeMap, 검색과 정렬 알고리즘에 활용하는 유틸리티 클래스인 Collections와 Arrays가 있다.

 compareTo의 순서가 equals의 결과가 일관되지 않은 경우 엇박자가 날 수 있는 데 예로 컬렉션 인터페이스에 정의된 동작에서 이다. 컬렉션 인터페이스들은 equals 메서드의 규약을 따른다고 되어 있지만, 정렬된 컬렉션들은 동치성을 비교할 때 equals 대신 compareTo를 사용하기 때문이다. 아주 큰 문제는 아니지만, 주의해야 한다.

 compareTo와 equals가 일관되지 않는 BigDecimal 클래스를 예로 생각해 보자. BigDecimal("1.0")과 BigDecimal("1.00")은 equals메소드로 비교하면 다르지만 compareTo 메소드로 비교하면 똑같다. 따라서 각 HashSet과 TreeSet에 삽입했을 때 원소의 개수가 다르다.

 

HashSet<BigDecimal> hashSet = new HashSet<>();
        TreeSet<BigDecimal> treeSet = new TreeSet<>();

        BigDecimal bigDecimal1 = new BigDecimal("1.0");
        BigDecimal bigDecimal2 = new BigDecimal("1.00");

        boolean compareTo = bigDecimal1.compareTo(bigDecimal2) == 0;

        boolean equals = bigDecimal1.equals(bigDecimal2);

        hashSet.add(bigDecimal1);
        hashSet.add(bigDecimal2);

        treeSet.add(bigDecimal1);
        treeSet.add(bigDecimal2);

        System.out.println(compareTo); // true
        System.out.println(equals); // false
        System.out.println(hashSet.size()); // 2
        System.out.println(treeSet.size()); // 1

 

 compreTo 메서드는 각 필드가 동치인지를 비교하는 게 아니라 그 순서를 비교한다. 객체 참조 필드를 비교하려면 compreTo 메서드를 재귀적으로 호출한다. Comprable을 구현하지 않은 필드나 표준이 아닌 순서로 비교해야 한다면 비교자(Comprable)를 대신 사용한다. 비교자는 직접 만들거나 자바가 제공하는 것 중 골라 쓰면 된다. 

 아래는 CaseInsensitivieString이 Comprable<CaseInsensitivieString>을 구현한 것으로 CaseInsensitivieString 참조와만 비교할 수 있다는 뜻이다. Comparable을 구현할 때 일반적으로 따르는 패턴이다.

public final class CaseInsensitiveString implements Comparable<CaseInsensitiveString>{

    private final String s;

    public CaseInsensitiveString(String s){
        if(s == null)
            throw new NullPointerException();
        this.s = s;
    }
    
    @Override
    public int compareTo(CaseInsensitiveString cis) {
        return String.CASE_INSENSITIVE_ORDER.compare(s, cis.s);
    }
}

 책의 2판에서는 정수 기본 타입 필드를 비교할 때 관계연산자인 <와 >를, 실수 기본 타입 필드를 비교할 때는 정적 메서드인 Double.compre와 Float.compare 사용을 권했지만 자바 7부터 박싱 된 기본 타입 클래스들에 새로 추가된 정적 메소드 compre를 이용하면 되게 되었다. compreTo 메서드에서 관계 연산자 <와 >를 사용하는 이전 방식은 거추장스럽고 오류를 유발하니, 이제는 추천하지 않는다.

 

 자바 8에서는 Comprator 인터페이스가 일련의 비교자 생성 메서드(comparator construction method)와 팀을 꾸려 메서드 연쇄 방식으로 비교자를 생성할 수 있게 되었다. 

 

    @Override
    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 0;
    }

 에서 적용한 모습이다. 간결하게 변하지만 다소 성능 저하가 발생할 수 있다.

 

    private static final Comparator<PhoneNumber> COMPARATOR =
            comparingInt((PhoneNumber pn) -> pn.areaCode)
            .thenComparingInt(pn -> pn.prefix)
            .thenComparingInt(pn -> pn.lineNum);

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

 

 이따금 '값의 차'를 기준으로 첫 번째 값이 두 번째 값보다 작으면 음수를, 두 값이 같으면 0을, 첫 번째 값이 크면 양수를 반환하는 compreTo나 compre메서드와 마주할 것이다. 다음이 예이다.

    static Comparator<Object> hashCodeOrder = new Comparator<>() {
        @Override
        public int compare(Object o1, Object o2) {
            return o1.hashCode() - o2.hashCode();
        }
    };

 이 방식은 사용하면 안 된다. 정수 오버플로를 일으키거나 IEEE 754 부동소수점 계산 방식에 따른 오류를 낼 수 있다.  따라서 다음 두 방식 중 하나를 사용하자.

 

    static Comparator<Object> hashCodeOrder1 = new Comparator<>() {
        @Override
        public int compare(Object o1, Object o2) {
            return Integer.compare(o1.hashCode(), o2.hashCode());
        }        
    }; 
    // hashCodeOrder1 압축 시
    static Comparator<Object> hashCodeOrder1 = comparingInt(Object::hashCode);    
    
    static Comparator<Object> hashCodeOrder2 = Comparator.comparingInt(o -> o.hashCode());

 

핵심 정리

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

---

📝 느낀점.

 equals, hashCode, toString, clone, compareTo 메서드들의 규약, 재정의를 언제 하는지, 어떻게 하는지에 대해 알 수 있는 장이였다.
 개발하면서 많이 접할 수 있는 영역이었다 보니 앞으로 재정의할 때 참고하면 좋을 것 같다.