[2주차] 7-14

Joshua Bloch 저 이복연 역 「Effective Java 3rd Edition, 2018」를 읽고 정리하였습니다.

아이템 7: finalized cleaner 사용을 피하라.

• 자바는 두 가지 객체 소멸자를 제공한다.

• finalizer는 기본적으로 쓰지 말아야 한다. 자바 9에서 deprecated API로 지정되고 cleaner를 그 대안으로 소개 했다.

• cleaner는 finalizer보다는 덜 위험하지만 여전히 예측할 수 없고 느리고 일반적으로 불 필요하다.

• 자바에서는 접근할 수 없게 된 객체를 회수하는 역할을 가비지 컬렉터가 담당한다.

• 자바에서는 try-withresources와 try-finally를 사용해 해결한다.

• finalizer와 cleaner는 즉시 수행된다는 보장이 없다. 따라서 제때 실행되어야 하는 작업에 절대 사용면 안된다.

• finalizer나 cleaner를 얼마나 신속히 수행할지는 전적으로 가비지 컬렉터 알고리즘에 달렸으며, 이는 가비지 컬렉터 구현마다 천차만별이다. 테스트한 JVM에서는 완벽하게 동작하던 프로그램이 가장 중요한 고객의 시스템에서는 엄청난 재앙을 일으킬지도 모른다.

• 저자 친구 GUI프로그램이 OutOfMemory 에러가 낫고, 원인은 객체 수천개가 finalizer에서 기다리고 있었는데... finalizer 스레드가 다른 애플리케이션 스레드보다 우선 순위가 낮아서 실행될 기회를 제대로 얻지 못한 것이다.

• 사례를 들어 데이터베이스 같은 공유 자원의 영구 락 해제를 finalizer나 cleaner에 맡겨 놓으면 분산 시스템 전체가 서서 히 멈출 것이다.

• System.gc나 System.runFinalization 메서드는 finalizer와 cleaner가 실행될 가능성을 높여줄 수는 있으나 보장해주진 않는다. 문제를 보장하기 위해 System.runFinalizersOnExit, Runtime.runFinalizersOnExit 메서드가 있어왔으나 심각한 결함이 있다.

• finalizer를 사용한 클래스는 finalizer 공격에 노출되어 심각한 보안 문제를 일으킬 수도 있다.

• 공격원리 -> 생성자나 직렬화 과정(ReadObject와 readResolve 메서드, 12장)에서 예외가 발생하면, 이 생성되다 만 객체에서 악의적인 하위 클래스의 finalizer가 수행될 수 있게 된다.

• AutoClosable은 12ns가 걸린 반면 finalizer를 사용하면 550ns 걸렸다. 안정망을 설치할때는 66ns가 걸렸다.

• 안전망: finalize() 안에서 close()를 호출해준다. FileInputStream 참고.

• 객체 생성을 막으려면 생성자에서 예외를 던지는 것만으로 충분하지만 finalizer가 있다면 그렇지도 않다.

아이템 8: finalized cleaner 사용을 피하라.

public class Room implements AutoCloseable {
    private static final Cleaner cleaner = Cleaner.create(); // 안정망으로 사용
​
    private final State state;
    private final Cleaner.Cleanable cleanable;
​
    Room(int numJunkPile) {
        System.out.println("쓰레기 수 = " + numJunkPile);
        state = new State(numJunkPile);
        cleanable = cleaner.register(this, state); // 등록할 때 State의 run 메서드 실행
    }
​
    private static class State implements Runnable { // 정적 중첩 클래스 = 바깥 객체의 참조 가질 수 x
        int numJunkPile;
​
        State(int numJunkPile) {
            this.numJunkPile = numJunkPile;
        }
​
        @Override
        public void run() {
            System.out.println("방 청소중");
            numJunkPile = 0;
        }
    }
​
    @Override
    public void close() throws Exception {
        cleanable.clean(); 
    }
​
    public static void main(String[] args) throws Exception {
//        //초보자
//        new Room(99);
//        System.out.println("쉬는 중");
//        System.gc(); // "방 청소중"이 나올 수도 안 나올 수도...
​
        // 고수
        try (Room myRoom = new Room(7)) { // 자동 청소 필요 없어진다.
            System.out.println("Goodbye");
        }
    }
​
}

더 현실적으로 만들려면 numJunkPile 필드는 네이티브 피어를 가리키는 포인터를 담은 final long 변수여야 한다.

run 메서드는 cleanable에 의해 딱 한 번만 호출된다. (등록시 호출)

State 인스턴스는 절대로 Room 인스턴스를 참조해서는 안 된다. 순환참조가 생겨 가비지 컬렉터가 Room 인스턴스를 회수 해갈 기회가 오지 않는다.

Room의 cleaner는 안전망으로만 쓰였다. 클라이언트가 모든 Room 생성을 try-with-resources 블록으로 감왔다면 자동 청소는 전혀 필요하지 않다.

이템 9: try-finally보다는 try-with-resources를 사용하라

자바 라이브러리에는 close 메서드를 호출해 직접 닫아줘야 하는 자원이 많다. Inputstream, Outputstream, java.sql.Connection 등좋은 예다. 자원 닫기는 클라이언트가 놓치기 쉬워서 예측할 수 없는 성능 문제로 이어지기도 한다. 이런 자원 중 상당수가 안전망으로 finalizer를 활용하고는 있지만 finalized 그리 믿을만하지 못하다(아이템 8).

public class Item09 {

    // 1 try-finally 사용
    static String firstLineOfFile01(String path) throws IOException {
        BufferedReader br = new BufferedReader(new FileReader(path));
        try {
            return br.readLine(); 
        }finally {
            br.close(); // readLine에서 예외 발생후, 여기서 예외 발생시 readLine 예외를 볼 수 없는 문제.. ★.★??
        }
    }

    // 2 try-with-resources 사용 (자바 7)
    static String firstLineOfFile02(String path) throws IOException {
        try(BufferedReader br = new BufferedReader(new FileReader(path));){
            // close에서 발생한 예외는 숨겨지고 readLine에서 발생한 예외가 기록된다.
            return br.readLine();
        }
    }

    public static void main(String[] args) throws IOException {
        String path = "src/com/larrykim/item09/data.txt";
//        System.out.println(Item09.firstLineOfFile01(path)); 
        System.out.println(Item09.firstLineOfFile02(path));
    }

}

만약 사용하는 자원이 두개였다면.. try-finally는 아래 같이 복잡해진다.

private static final int BUFFER_SIZE = 8 * 1024;

// 1 try-finally 
static void copy(String src, String dst) throws IOException {
    InputStream in = new FileInputStream(src);
    try {
        OutputStream out = new FileOutputStream(dst);
        try {
            byte[] buf = new byte[BUFFER_SIZE];
            int n;
            while ((n = in.read(buf)) >= 0)
                out.write(buf, 0, n);
        } finally {
            out.close(); // 명시적으로 close
        }
    } finally {
        in.close(); // 명시적으로 close
    }
}
------------------------------------------------------------
// 2 try-with-resources
static void copy(String src, String dst) throws IOException {
    try (InputStream in = new FileInputStream(src);
         OutputStream out = new FileOutputStream(dst)) {
        byte[] buf = new byte[BUFFER_SIZE];
        int n;
        while ((n = in.read(buf)) >= 0)
            out.write(buf, 0, n);
 }

그리고 try-finally 문을 제대로 사용한 앞의 두 예제 조차 미묘한 결점이 있다. 예외는 try 블록과 finally 블록 모두에서 발생할 수 있는데, 예컨대 기기에 물리적인 문제가 생긴다면 firstLineOfFile01 메서드 안의 readLine 메서드가 예외를 던지고 같은 이유로 close 메서드도 실패할 것이다. 이런 상황이라면 두 번째 예외가 첫 번째 예외를 완전히 집어삼켜 버린다. 그러면 스택 추적 내역에 첫 번째 예외에 관한 정보는 남지 않게 되어 실제 시스템에서의 디버깅을 몹시 어렵게 한다(일반적으로 문제를 진단하려면 처음 발생한 예외를 보고 싶을 것이다).

static IOException firstLineOfFile01(String path) throws IOException {
    BufferedReader br = new BufferedReader(new FileReader(path));
    try {
        return new IOException("try 에러");
    } catch (Exception e) {
        e.printStackTrace();
    } finally {
        return new IOException("finally 에러");
    }
}

대비되는 try-with-resources 장점

close에서 발생한 예외는 숨겨지고 readLine에서 발생한 예외가 기록된다. 이렇게 숨겨진 예외들도 그냥 버려지지는 않고, 스택 추적 내역에 "숨겨졌다"는 (suppressed) 꼬리표를 달고 출력된다. 또한, 자바 7에서 Throwable에 추가 된 getSuppressed()를 이용하면 프로그램 코드에서 가져올 수도 있다. try-with-resource suppressed 예제

총코드

public class Item09 {
    private static final int BUFFER_SIZE = 8 * 1024;

    static String firstLineOfFile_tryFinally(String path) throws IOException {
        BufferedReader br = new BufferedReader(new FileReader(path));
        try {
            return br.readLine();
        } finally {
            br.close();
        }
    }

    static String firstLineOfFile0_tryWithResources(String path) throws IOException {
        try (BufferedReader br = new BufferedReader(new FileReader(path));) {
            return br.readLine();
        }
    }

    static void copy_tryWithResources(String src, String dst) throws IOException {
        try (InputStream in = new FileInputStream(src);
             OutputStream out = new FileOutputStream(dst)) {
            byte[] buf = new byte[BUFFER_SIZE];
            int n;
            while ((n = in.read(buf)) >= 0) {
                System.out.println("쓰기할 바이트 수 = " + n);
                out.write(buf, 0, n); // 데이터, 시작점, 쓰기할 바이트수
            }
        }
    }

    public static void main(String[] args) throws IOException {
//        String path = "src/com/larrykim/common/data.txt";
////        System.out.println(Item09.firstLineOfFile_tryFinally(path));
//        System.out.println(Item09.firstLineOfFile0_tryWithResources(path));

        String src = "src/com/larrykim/common/data.txt";
        String dst = "src/com/larrykim/common/data_dst.txt";
        copy_tryWithResources(src, dst);
    }
}

요약, 꼭 회수해야 하는 자원을 다룰 때는 try-finally 말고, try-with-resources를 사용하자.

3장 모든 객체의 공통 메서드 (10-14)

Object는 객체를 만들 수 있는 구체 클래스지만 기본적으로는 상속해서 사용하도록 설계되었다. Object에서 final이 아닌 메서드(equals, hashCode, toString, clone, finalize)는 모두 재정의(overriding)를 염두에 두고 설계된 것이라 재정의 시 지켜야 하는 일반 규약이 (general contracts) 명확히 정의되어 있다. 그래서 Object를 상속하는 클래스, 즉 모든 클래스는 이 메서드들을 일반 규약에 맞게 재정의해야 한다. 메서드를 잘못 구현하면 대상 클래스가 이 규약을 준수한다고 가정하는 클래스(HashMap과 HashSet 등)를 오동작하게 만들 수 있다.

이번 장에서는 final이 아닌 Object 메서드들을 언제 어떻게 재정의해야 하는지를 다룬다.

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

다음 중 하나에 해당한다면 equals를 재정의하지 않는 것이 최선이다.

• 각 인스턴스가 본질적으로 고유하다. 예를들어, Thread

• 인스턴스의 '논리적 동치성(logical equality)’을 검사할 일이 없다. 예를들어, Pattern.

  public class RegexExample {
    public static void main(String[] args)  {
  
            String pattern = "^[0-9]*$"; //숫자만
            String val = "123456789"; //대상문자열
  
            boolean regex = Pattern.matches(pattern, val);
            System.out.println(regex);
    }
  }

• 상위 클래스에서 재정의한 equals가 하위 클래스에도 딱 들어맞는다. List, Set, Map - AbstractList, AbstractSet, AbstractMap의 equals 상속받아 사용한다.

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

재정의를 해야 될때는 언제일까?

객체 식별성이 아니라 (object identity 두 객체가 물리적으로 같은가) 논리적 동치성을 확인해야 하는데, 상위 클래스의equals가 논리적 동치성을 비교하도록 재정의되지 않았을 때다. 주로 값클래스들이 (Integer, String) 해당된다. 객체가 같은 지가 아니라 값이 같은지가 궁금할 것이다. 논리적 동치성을 판단하도록 재정의하면, 인스턴스 값을 비교도 할 뿐만 아니라 Map의 키와 Set의 원소로 쓸 수 있다.

equals 메서드 재정의시 지켜야할 규약

• 반사성 reflexibility

• 대칭성 symmetry

• 추이성 transitivity

• 일관성 consistency

• null-아님

x.equals(x)
x.equals(y) y.equals(x)
x.equals(y) y.equals(z) x.equals(z) 
x.equals(y) 반복호출
x.equals(null)

세상에 홀로 존해하는 클래스는 없다. 한 클래스의 인스턴스는 다른 곳으로 빈번히 전달된다. 그리고 컬렉션 클래스들을 포함해 수많은 클래스는 전달받은 객체가 equals 규약을 지킨다고 가정하고 동작한다.

동치관계를 만족시키기 위한 다섯 요건을 하나씩 살펴보자.

동치관계 = 집합을 서로같은원소들로 이뤄진 부분집합(동치류, equivalence class)으로 나누는 연산. equals 메서드가 쓸모 있으려면 모든 원소가 같은 동치류에 속한 어떤 원소와도 서로 교환할 수 있어야 한다.

// 동치 비교(equivalence) vs 동일성 비교(identity)
Member member1 = new Member("김유철", "강남");
Member member2 = new Member("김유철", "강남");

System.out.println(member1 == member2); //false
System.out.println(member1.equals(member2); //true

//Member member1 = new Member("김유철", "강남");
//Member member2 = member1;

//System.out.println(member1 == member2); //true
//System.out.println(member1.equals(member2)); //true

------------------------------------------------------------
public class Member {
    private String name;
    private String address;

    public Member(String name, String address) {
        this.name = name;
        this.address = address;
    }
}
------------------------------------------------------------
Member member1 = new Member("김유철","강남");
Member member2 = new Member("김유철","강남");

//1 reflexibility
System.out.println(member1.equals(member1)); 

//2 symmetry
System.out.println(member1.equals(member2));
System.out.println(member2.equals(member1));

//3 transitivity
Member member3 = new Member("김유철","강남");
System.out.println(member1.equals(member2));
System.out.println(member2.equals(member3));
System.out.println(member1.equals(member3));

//4 consistency
System.out.println(member1.equals(member3));
System.out.println(member1.equals(member3));
System.out.println(member1.equals(member3));

반사성 reflexibility

이 요건은 일부러 어기는 경우가 아니라면 만족시키지 못하기 더 어렵다.

대칭성 symmetry

위배 사례를 보자.

public final class CaseInsensitiveString {
    private final String s;

    public CaseInsensitiveString(String s) {
        this.s = Objects.requireNonNull(s);
    }

    //1 
    @Override public boolean equals(Object o) {
        if (o instanceof CaseInsensitiveString)
            return s.equalsIgnoreCase(
                    ((CaseInsensitiveString) o).s);
        if (o instanceof String) 
            return s.equalsIgnoreCase((String) o);
        return false;
    }

    public static void main(String[] args) {
        CaseInsensitiveString cis = new CaseInsensitiveString("Polish"); //대
        String s = "polish"; //소

        System.out.println(cis.equals(s)); //true
        System.out.println(s.equals(cis)); //false

    }
}
------------------------------------------------------
public final class CaseInsensitiveString {
    private final String s;

    public CaseInsensitiveString(String s) {
        this.s = Objects.requireNonNull(s);
    }

    //2 CaseInsensitiveString가 String과 비교를 가능하게 하겠다는 꿈을 버리자.
    @Override
    public boolean equals(Object o) {
        return o instanceof CaseInsensitiveString &&
            ((CaseInsensitiveString) o).s.equalsIgnoreCase(s);
    }

    public static void main(String[] args) {
        CaseInsensitiveString cis = new CaseInsensitiveString("Polish"); //대
        String s = "polish"; //소

        System.out.println(s.equals(cis));
        System.out.println(cis.equals(s));
    }
}

추이성 transitivity

Color enum 생성 -> Point 부모 -> ColorPoint 자식

public enum Color {
    RED, GREEN, BLACK
}

//1 대칭성부터 위배
public class Point {
    private final int x;
    private final int y;

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

    @Override
    public boolean equals(Object o) { 
        if (!(o instanceof Point)) return false; //상속관계에서 instanceof 비교 사용
        Point point = (Point) o;
        return x == point.x && y == point.y;
    }
}

public class ColorPoint extends Point {
    private final Color color;

    public ColorPoint(int x, int y, Color color) {
        super(x, y);
        this.color = color;
    }

    @Override public boolean equals(Object o) {
        if (!(o instanceof ColorPoint))
            return false;
        return super.equals(o) && ((ColorPoint) o).color == color;
    }

    public static void main(String[] args) {
        Point point = new Point(1, 2);
        Point colorPoint = new ColorPoint(1, 2, Color.RED);

        System.out.println(point.equals(colorPoint)); //true
        System.out.println(colorPoint.equals(point)); //false
    }
}
---------------------------------------------------------
//2 대칭성은 맞지만, 추이성 위배
public class Point {
    private final int x;
    private final int y;

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

    @Override
    public boolean equals(Object o) { 
        if (!(o instanceof Point)) return false; //상속관계에서 instanceof 비교 사용
        Point point = (Point) o;
        return x == point.x && y == point.y;
    }
}

public class ColorPoint extends Point {
    private final Color color;

    public ColorPoint(int x, int y, Color color) {
        super(x, y);
        this.color = color;
    }

    @Override public boolean equals(Object o) {
        if (!(o instanceof Point))
            return false;

        if (!(o instanceof ColorPoint)) 
            return o.equals(this); // 대칭성 만족

        return super.equals(o) && ((ColorPoint) o).color == color;
    }

    public static void main(String[] args) {
        Point point = new Point(1, 2);
        Point colorPoint1 = new ColorPoint(1, 2, Color.GREEN);
        Point colorPoint2 = new ColorPoint(1, 2, Color.RED);

        System.out.println(point.equals(colorPoint1)); //true
        System.out.println(point.equals(colorPoint2)); //true
        System.out.println(colorPoint1.equals(colorPoint2)); //false
        //추이성 위배
    }
}

또다른 하위클래스 있을시, 재귀 위험도 있을 수 있다.

public class SmellPoint extends Point{
    private final String name;

    public SmellPoint(int x, int y, String name) {
        super(x, y);
        this.name = name;
    }

    @Override public boolean equals(Object o) {
        if(!(o instanceof Point))
            return false;

        if (!(o instanceof SmellPoint))
            return o.equals(this);
        return super.equals(o) && ((SmellPoint) o).name.equals(name);
    }
}

public static void main(String[] args) {
    Point point = new Point(1, 2);
    Point colorPoint = new ColorPoint(1, 2, Color.GREEN);
    Point smellPoint = new SmellPoint(1,2,"Larry");

    System.out.println(point.equals(colorPoint)); //true
    System.out.println(point.equals(smellPoint)); //true
    System.out.println(colorPoint.equals(smellPoint)); //무한재귀 StackOverflowError
}

해결 방법은 무엇일까?

구체 클래스를 확장해 새로운 값을 추가하면서 equals 규약을 만족시킬 방법은 존재하지 않는다. 객체 지향적 추상화의 이점을 포기하지 않는 한은 말이다. 이 말은 얼핏, equals 안의 instanceof 검사를 getClass 검사로 바꾸면 규약도 지키고 값도 추가하면서 구체 클래스를 상속할 수 있다는 뜻으로 들린다. (아래)

@Override public boolean equals(Object o) {
    if (o == null || o.getClass() != getClass())
        return false;
    Point p = (Point) o;
    return p.x == x && p.y == y;
}

하지만 실제 활용할 수는 없다. 예를 들기 위해, 주어진 점이 (반지름이 1인) 단위 원 안에 있는지를 판별하는 메서드가 필요하다고 해보자.

리스코프 치환 원칙에 따르면, Point의 하위 클래스는 정의상 여전히 Point이므로 어디서든 Point로써 활용될 수 있어야 한다. 그러나 CounterPoint의 인스턴스를 onUnitCircle 메서드에 넘기면 어떻게 될까? false반환.

Set을 포함하여 대부분의 컬렉션은 contains 작업에 equals 메서드를 이용하는데, CounterPoint의 인스턴스는 어떤 Point와도 같을 수 없기 때문이다.

// Initialize unitCircle to contain all Points on the unit circle
// CounterPointTest 클래스
public class CounterPointTest {
    private static final Set<Point> unitCircle =
            Set.of(new Point(1,0),new Point(0,1),new Point(-1,0),new Point(0,-1));

    public static boolean onUnitCircle(Point p){
        return unitCircle.contains(p);
    }

    public static void main(String[] args) {
        CounterPoint counterPoint = new CounterPoint(1,0);
        System.out.println(onUnitCircle(counterPoint)); //false
        //Set을 포함하여 대부분의 컬렉션은 contains 작업에 equals 메서드를 이용하는데,
        // CounterPoint의 인스턴스는 어떤 Point와도 같을 수 없기 때문이다.
    }
}
---------------------------------------------------------------------
public class CounterPoint extends Point {
    private static final AtomicInteger counter =
            new AtomicInteger();
    public CounterPoint(int x, int y) {
        super(x, y);
        counter.incrementAndGet();
    }
    public static int numberCreated() { return counter.get(); }
}

구체 클래스의 하위 클래스에서 값을 추가할 방법은 없지만 괜찮은 우회 방법이 하나 있다. 합성.

// equals 규약 위배 없이 합성 사용

public class ColorPoint {
    private final Point point;
    private final Color color;

    public ColorPoint(int x, int y, Color color) {
        point = new Point(x, y);
        this.color = Objects.requireNonNull(color);
    }

    public Point asPoint() {
        return point;
    }

    @Override public boolean equals(Object o) {
        if (!(o instanceof ColorPoint))
            return false;
        ColorPoint cp = (ColorPoint) o;
        return cp.point.equals(point) && cp.color.equals(color);
    }

    @Override public int hashCode() {
        return 31 * point.hashCode() + color.hashCode();
    }

    public static void main(String[] args) {
        Point point = new Point(1, 2);
        ColorPoint colorPoint1 = new ColorPoint(1, 2, Color.GREEN);
        ColorPoint colorPoint2 = new ColorPoint(1, 2, Color.RED);

        System.out.println(point.equals(colorPoint1)); //true
        System.out.println(point.equals(colorPoint2)); //true
        System.out.println(colorPoint2.equals(colorPoint1)); //true
    }
}

자바 라이브러리에도 구체 클래스를 확장해 값을 추가한 클래스가 종종 있다. Timestamp는 Date를 확장한 후 nanoseconds 필드를 추가했다. 그 결과로 Timestamp의 equals는 대칭성을 위배하며, Date 객체와 한 컬렉션에 넣거나 서로 섞어 사용하면 엉뚱하게 동작할 수 있다. Timestamp를 이렇게 설계한 것은 실수니 절대 따라 해서는 안된다.

Timestamp stamp = new Timestamp(System.currentTimeMillis());
Date date = new Date(stamp.getTime());
System.out.println(stamp.equals(date));
System.out.println(date.equals(stamp));

일관성 consistency

두 객체가 같다면 (어느 하나 혹은 두 객체 모두가 수정되지 않는 한) 앞으로도 영원히 같아야 한다는 뜻이다.

클래스가 불변이든 가변이든 equals의 판단에 신뢰할 수 없는 자원이 끼어들게 해서는 안 된다. 이 제약을 어기면 일관성 조건을 만족시키기가 아주 어렵다. 예컨대 java.net.URL의 equlas는 URL과 IP 주소를 이용해 비교한다

URL을 저렇게 만든건 실수였으니 절대 따라 해서는 안 된다. 이런 문제를 피하려면 equals는 항시 메모리에 존재하는 객체만을 사용한 결정적(deterministic) 계산만 수행해야 한다.

URL url1 = new URL("www.naver.com");
URL url2 = new URL("www.naver.com");
url1.equals(url2) //true

//중간로직


url2 = new URL("www.naver.com");
url1.equals(url2) //false


url1.equals(url2)

null-아님

모든 객체가 null과 같지 않아야 한다는 뜻이다.

// 명시적 널 검사 - 필요없다!
@Override public boolean equals(Object o) {
    if (o == null)
        return false;
    ...
}

// 묵시적 널 검사 - 이게 낫다.
@Override public boolean equals(Object o) {
    if (!(o instanceof MyType)) // 널이면 false 반환
        return false;
    MyType mt = (MyType) o;
    ...
}

지금까지의 내용을 종합해서 equals 메서드 구현

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

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

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

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

public final class PhoneNumber {
    private final short areaCode, prefix, lineNum;
    public PhoneNumber(int areaCode, int prefix, int lineNum) {
        this.areaCode = rangeCheck(areaCode, 999, "area code");
        this.prefix = rangeCheck(prefix, 999, "prefix");
        this.lineNum = rangeCheck(lineNum, 9999, "line num");
    }
    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) // 1 자기 자신의 참조인지 확인
            return true;
        if (!(o instanceof PhoneNumber)) // 2 올바른 타입인지 확인
            return false;
        PhoneNumber pn = (PhoneNumber)o; // 3 올바른 타입으로 형변환, instanceof가 성공했으면 이것은 100퍼센트!
        return pn.lineNum == lineNum && pn.prefix == prefix
            && pn.areaCode == areaCode; // 4 핵심 필드들이 일치하는지 검사
    }
    ... // Remainder omitted
}

3장 모든 객체의 공통 메서드 (10-14)

Object는 객체를 만들 수 있는 구체 클래스지만 기본적으로는 상속해서 사용하도록 설계되었다. Object에서 final이 아닌 메서드(equals, hashCode, toString, clone, finalize)는 모두 재정의(overriding)를 염두에 두고 설계된 것이라 재정의 시 지켜야 하는 일반 규약이 (general contracts) 명확히 정의되어 있다. 그래서 Object를 상속하는 클래스, 즉 모든 클래스는 이 메서드들을 일반 규약에 맞게 재정의해야 한다. 메서드를 잘못 구현하면 대상 클래스가 이 규약을 준수한다고 가정하는 클래스(HashMap과 HashSet 등)를 오동작하게 만들 수 있다.

이번 장에서는 final이 아닌 Object 메서드들을 언제 어떻게 재정의해야 하는지를 다룬다.

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

다음 중 하나에 해당한다면 equals를 재정의하지 않는 것이 최선이다.

• 각 인스턴스가 본질적으로 고유하다. 예를들어, Thread.

• 인스턴스의 '논리적 동치성(logical equality)’을 검사할 일이 없다. 예를들어, Pattern.

• 상위 클래스에서 재정의한 equals가 하위 클래스에도 딱 들어맞는다. List, Set, Map - AbstractList, AbstractSet, AbstractMap의 equals 상속받아 사용한다.

• 클래스가 private이거나 package-private이고 equals 메서드를 호출할 일이 없다. 무슨말?

재정의를 해야 될때는 언제일까?

객체 식별성이 아니라 (object identity 두 객체가 물리적으로 같은가) 논리적 동치성을 확인해야 하는데, 상위 클래스의equals가 논리적 동치성을 비교하도록 재정의되지 않았을 때다. 주로 값클래스들이 (Integer, String) 해당된다. 객체가 같은 지가 아니라 값이 같은지가 궁금할 것이다. 논리적 동치성을 판단하도록 재정의하면, 인스턴스 값을 비교도 할 뿐만 아니라 Map의 키와 Set의 원소로 쓸 수 있다.

무슨말?@@ -> 값을 비교하지 않고 물리적인 위치를 비교할때 재정의 해야된다는거지?

equals 메서드 재정의시 지켜야할 규약 - 그림 그리며 설명

• 반사성 reflexibility

• 대칭성 symmetry

• 추이성 transitivity

• 일관성 consistency

• null-아님

x.equals(x)
x.equals(y) y.equals(x)
x.equals(y) y.equals(z) x.equals(y) 
x.equals(y) 반복호출
x.equals(null)

세상에 홀로 존해하는 클래스는 없다. 한 클래스의 인스턴스는 다른 곳으로 빈번히 전달된다. 그리고 컬렉션 클래스들을 포함해 수많은 클래스는 전달받은 객체가 equals 규약을 지킨다고 가정하고 동작한다.

동치관계 = 집합을 서로같은원소들로 이뤄진 부분집합(동치류, equivalence class)으로 나누는 연산. equals 메서드가 쓸모 있으려면 모든 원소가 같은 동치류에 속한 어떤 원소와도 서로 교환할 수 있어야 한다. 동치관계를 만족시키기 위한 다섯 요건을 하나씩 살펴보자.

// 동치 비교(equivalence) vs 동일성 비교(identity)
Member member1 = new Member("김유철", "강남");
Member member2 = new Member("김유철", "강남");

System.out.println(member1 == member2);
System.out.println(member1.equals(member2));    

System.out.println(member1.hashCode());
System.out.println(member2.hashCode());

//Member member1 = new Member("김유철", "강남");
//Member member2 = member1;

//System.out.println(member1 == member2);
//System.out.println(member1.equals(member2));

------------------------------------------------------------
public class Member {
    private String name;
    private String address;

    public Member(String name, String address) {
        this.name = name;
        this.address = address;
    }
}
------------------------------------------------------------
Member member1 = new Member("김유철","강남");
Member member2 = new Member("김유철","강남");

//1
System.out.println(member1==member2); //물리적으로 다르지만
System.out.println(member1.equals(member2)); //같은값을 가진 객체이다.

//2 reflexibility
System.out.println(member1.equals(member2));
System.out.println(member2.equals(member1));

//3 transitivity
Member member3 = new Member("김유철","강남");
System.out.println(member1.equals(member2));
System.out.println(member2.equals(member3));
System.out.println(member1.equals(member3));

//4 consistency
System.out.println(member1.equals(member3));
System.out.println(member1.equals(member3));
System.out.println(member1.equals(member3));

반사성 reflexibility

대칭성 symmetry

위배 사례를 보자.

public final class CaseInsensitiveString {
    private final String s;

    public CaseInsensitiveString(String s) {
        this.s = Objects.requireNonNull(s);
    }

    //1 
    @Override public boolean equals(Object o) {
        if (o instanceof CaseInsensitiveString)
            return s.equalsIgnoreCase(
                    ((CaseInsensitiveString) o).s);
        if (o instanceof String) 
            return s.equalsIgnoreCase((String) o);
        return false;
    }

    public static void main(String[] args) {
        CaseInsensitiveString cis = new CaseInsensitiveString("Polish"); //대
        String s = "polish"; //소

        System.out.println(s.equals(cis));
        System.out.println(cis.equals(s));
    }
}
------------------------------------------------------
public final class CaseInsensitiveString {
    private final String s;

    public CaseInsensitiveString(String s) {
        this.s = Objects.requireNonNull(s);
    }

    //2 CaseInsensitiveString가 String과 비교를 가능하게 하겠다는 꿈을 버리자.
    @Override
    public boolean equals(Object o) {
        return o instanceof CaseInsensitiveString &&
            ((CaseInsensitiveString) o).s.equalsIgnoreCase(s);
    }

    public static void main(String[] args) 
        CaseInsensitiveString cis = new CaseInsensitiveString("Polish"); //대
        String s = "polish"; //소

        System.out.println(s.equals(cis));
        System.out.println(cis.equals(s));
    }
}

추이성 transitivity

Color enum 생성 -> Point 부모 -> ColorPoint 자식

public enum Color {
    RED, GREEN, BLACK
}

//1 대칭성부터 위배
public class Point {
    private final int x;
    private final int y;

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

    @Override
    public boolean equals(Object o) { 
        if (!(o instanceof Point)) return false; //상속관계에서 instanceof 비교 사용
        Point point = (Point) o;
        return x == point.x && y == point.y;
    }
}

public class ColorPoint extends Point {
    private final Color color;

    public ColorPoint(int x, int y, Color color) {
        super(x, y);
        this.color = color;
    }

    @Override public boolean equals(Object o) {
        if (!(o instanceof ColorPoint))
            return false;
        return super.equals(o) && ((ColorPoint) o).color == color;
    }

    public static void main(String[] args) {
        Point point = new Point(1, 2);
        Point colorPoint = new ColorPoint(1, 2, Color.RED);

        System.out.println(point.equals(colorPoint)); //true
        System.out.println(colorPoint.equals(point)); //false
    }
}
---------------------------------------------------------
//2 대칭성은 맞지만, 추이성 위배
public class Point {
    private final int x;
    private final int y;

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

    @Override
    public boolean equals(Object o) { 
        if (!(o instanceof Point)) return false; //상속관계에서 instanceof 비교 사용
        Point point = (Point) o;
        return x == point.x && y == point.y;
    }
}

public class ColorPoint extends Point {
    private final Color color;

    public ColorPoint(int x, int y, Color color) {
        super(x, y);
        this.color = color;
    }

    @Override public boolean equals(Object o) {
        if (!(o instanceof Point))
            return false;

        if (!(o instanceof ColorPoint)) 
            return o.equals(this); // 대칭성 만족

        return super.equals(o) && ((ColorPoint) o).color == color;
    }

    public static void main(String[] args) {
        Point point = new Point(1, 2);
        Point colorPoint1 = new ColorPoint(1, 2, Color.GREEN);
        Point colorPoint2 = new ColorPoint(1, 2, Color.RED);

        System.out.println(point.equals(colorPoint1)); //true
        System.out.println(point.equals(colorPoint2)); //true
        System.out.println(colorPoint1.equals(colorPoint2)); //false
        //추이성 위배
    }
}

또다른 하위클래스 있을시, 재귀 위험도 있을 수 있다.

public class SmellPoint extends Point{
    private final String name;

    public SmellPoint(int x, int y, String name) {
        super(x, y);
        this.name = name;
    }

    @Override public boolean equals(Object o) {
        if(!(o instanceof Point))
            return false;

        if (!(o instanceof SmellPoint))
            return o.equals(this);
        return super.equals(o) && ((SmellPoint) o).name.equals(name);
    }
}

public static void main(String[] args) {
    Point point = new Point(1, 2);
    Point colorPoint = new ColorPoint(1, 2, Color.GREEN);
    Point smellPoint = new SmellPoint(1,2,"Larry");

    System.out.println(point.equals(colorPoint)); //true
    System.out.println(point.equals(smellPoint)); //true
    System.out.println(colorPoint.equals(smellPoint)); //무한재귀 StackOverflowError
}

해결 방법은 무엇일까?

d아래 이해 안되@@@

구체 클래스를 확장해 새로운 값을 추가하면서 equals 규약을 만족시킬 방법은 존재하지 않는다. 객체 지향적 추상화의 이점을 포기하지 않는 한은 말이다. 이 말은 얼핏, equals 안의 instanceof 검사를 getClass 검사로 바꾸면 규약도 지키고 값도 추가하면서 구체 클래스를 상속할 수 있다는 뜻으로 들린다. (아래)

@Override public boolean equals(Object o) {
    if (o == null || o.getClass() != getClass())
        return false;
    Point p = (Point) o;
    return p.x == x && p.y == y;
}

하지만 실제 활용할 수는 없다. 예를 들기 위해, 주어진 점이 (반지름이 1인) 단위 원 안에 있는지를 판별하는 메서드가 필요하다고 해보자.

리스코프 치환 원칙에 따르면, Point의 하위 클래스는 정의상 여전히 Point이므로 어디서든 Point로써 활용될 수 있어야 한다. 그러나 CounterPoint의 인스턴스를 onUnitCircle 메서드에 넘기면 어떻게 될까? false반환.

Set을 포함하여 대부분의 컬렉션은 contains 작업에 equals 메서드를 이용하는데, CounterPoint의 인스턴스는 어떤 Point와도 같을 수 없기 때문이다.

// Initialize unitCircle to contain all Points on the unit circle
// CounterPointTest 클래스
public class CounterPointTest {
    private static final Set<Point> unitCircle =
            Set.of(new Point(1,0),new Point(0,1),new Point(-1,0),new Point(0,-1));

    public static boolean onUnitCircle(Point p){
        return unitCircle.contains(p);
    }

    public static void main(String[] args) {
        CounterPoint counterPoint = new CounterPoint(1,0);
        System.out.println(onUnitCircle(counterPoint)); //false
        //Set을 포함하여 대부분의 컬렉션은 contains 작업에 equals 메서드를 이용하는데,
        // CounterPoint의 인스턴스는 어떤 Point와도 같을 수 없기 때문이다.
    }
}
---------------------------------------------------------------------
public class CounterPoint extends Point {
    private static final AtomicInteger counter =
            new AtomicInteger();
    public CounterPoint(int x, int y) {
        super(x, y);
        counter.incrementAndGet();
    }
    public static int numberCreated() { return counter.get(); }
}

구체 클래스의 하위 클래스에서 값을 추가할 방법은 없지만 괜찮은 우회 방법이 하나 있다. 합성.

아래가 위 문제를 해결해주는지 테스트 해보기@@@@

// equals 규약 위배 없이 합성 사용
public class ColorPoint {
    private final Point point;
    private final Color color;
    public ColorPoint(int x, int y, Color color) {
        point = new Point(x, y);
        this.color = Objects.requireNonNull(color);
    }

    //포인트 반환 뷰 메서드
    public Point asPoint() {
        return point;
    }
    @Override public boolean equals(Object o) {
        if (!(o instanceof ColorPoint))
            return false;
        ColorPoint cp = (ColorPoint) o;
        return cp.point.equals(point) && cp.color.equals(color);
    }
... // 생략
}

자바 라이브러리에도 구체 클래스를 확장해 값을 추가한 클래스가 종종 있다. Timestamp는 Date를 확장한 후 nanoseconds 필드를 추가했다. 그 결과로 Timestamp의 equals는 대칭성을 위배하며, Date 객체와 한 컬렉션에 넣거나 서로 섞어 사용하면 엉뚱하게 동작할 수 있다. Timestamp를 이렇게 설계한 것은 실수니 절대 따라 해서는 안된다.

직접 보여주면 조겠음@@ api에 주의사항 위배해서 만든경우와 잘 작성한경우...@@

일관성 consistency

클래스가 불변이든 가변이든 equals의 판단에 신뢰할 수 없는 자원이 끼어들게 해서는 안 된다. 이 제약을 어기면 일관성 조건을 만족시키기가 아주 어렵다. 예컨대 java.net.URL의 equlas는 URL과 IP 주소를 비교한다

~~ 사이 이해안됨..

실수였으니 절대 따라 해서는 안 된다. 이런 문제를 피하려면 equals는 항시 메모리에 존재하는 객체만을 사용한 결정적(deterministic) 계산만 수행해야 한다.

null-아님

모든 객체가 null과 같지 않아야 한다는 뜻이다.

// 명시적 널 검사 - 필요없다!
@Override public boolean equals(Object o) {
    if (o == null)
        return false;
    ...
}

// 묵시적 널 검사 - 이게 낫다.
@Override public boolean equals(Object o) {
    if (!(o instanceof MyType)) // 널이면 false 반환
        return false;
    MyType mt = (MyType) o;
    ...
}

위에 instanceof 널이었으면 어떤 결과가 나올까!! @@@????

지금까지의 내용을 종합해서 equals 메서드 구현

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

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

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

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

public final class PhoneNumber {
    private final short areaCode, prefix, lineNum;
    public PhoneNumber(int areaCode, int prefix, int lineNum) {
        this.areaCode = rangeCheck(areaCode, 999, "area code");
        this.prefix = rangeCheck(prefix, 999, "prefix");
        this.lineNum = rangeCheck(lineNum, 9999, "line num");
    }
    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) // 1 자기 자신의 참조인지 확인
            return true;
        if (!(o instanceof PhoneNumber)) // 2 올바른 타입인지 확인
            return false;
        PhoneNumber pn = (PhoneNumber)o; // 3 올바른 타입으로 형변환, instanceof가 성공했으면 이것은 100퍼센트!
        return pn.lineNum == lineNum && pn.prefix == prefix
            && pn.areaCode == areaCode; // 4 핵심 필드들이 일치하는지 검사
    }
    ... // Remainder omitted
}

// Broken - parameter type must be Object!
public boolean equals(MyClass o) {
    //...
}

// Still broken, but won’t compile
@Override public boolean equals(MyClass o) {
    //...
}

생략@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

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

//멤버에 name, address 멤버 변수가 있다.
Member member1 = new Member("이름1","주소1");
Member member2 = new Member("이름1","주소1");

System.out.println(member1==member2); // false 
System.out.println(member1.equals(member2)); // true 
System.out.println(member1.hashCode()==member2.hashCode()); // true

equals를 재정의한 클래스 모두에서 hashCode도 재정의해야 한다. 그렇지 않으면 hashCode 일반 규약을 어기게 되어 해당 클래스의 인스턴스를 HashMap이나 HashSet 같은 컬렉션의 원소로 사용할 때 문제를 일으킨다.

• Object 명세에서 발췌한 규약

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

  2. equals가 두 객체를 같다고 판단했다면, 두 객체의 hashCode는 똑같은 값을 반환해야 한다. -> 재정의 잘못했을때 가장 문제가 되는 조항.

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

Hash function을 수행하여 관리하는 HashMap 예제를 확인해보자.

Map<PhoneNumber, String> m = new HashMap<>();

왜 다르 값이 나올까? - 두번째 Contract 위배

public final class PhoneNumber {
    private final short areaCode, prefix, lineNum;

    public PhoneNumber(int areaCode, int prefix, int lineNum) {
        this.areaCode = rangeCheck(areaCode, 999, "area code");
        this.prefix   = rangeCheck(prefix,   999, "prefix");
        this.lineNum  = rangeCheck(lineNum, 9999, "line num");
    }

    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) { //equals는 재정의
        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 재정의 하지 않았음. (문제 원인)
}
----------------------------------------------------------------------
Map<PhoneNumber, String> m = new HashMap<>();
m.put(new PhoneNumber(707, 867, 5309), "Jenny");
System.out.println(m.get(new PhoneNumber(707, 867, 5309))); // null
//equals가 두 객체를 같다고 판단했다면, 두 객체의 hashCode는 똑같은 값을 반환해야 한다. (위배)

//내가 만든 예제 - PhoneNumber String 위치 바꿈
Map<String, PhoneNumber> pnMap = new HashMap<>();
pnMap.put("Jenny",new PhoneNumber(707, 867, 5309)); //키값 제니: 전화번호 707-867-5309

System.out.println(new PhoneNumber(707, 867, 5309).equals(pnMap.get("Jenny"))); //true
System.out.println(new PhoneNumber(707, 867, 5309).hashCode()); //93122545
System.out.println(pnMap.get("Jenny").hashCode()); //2083562754
//팁-해시코드는 32비트 정수 내

좋은 hashCode를 작성하는 요령 무슨말

1. int 변수 result를 선언한 후 값 c로 초기화한다.

2. 해당객체의 나머지 핵심필드 f 각각에 대해 다음작업을 수행한다.

   1. 해당 필드의 해시코드 c를 계산한다.

   2. 단계 2.1에서 계산한 해시코드 c로 result를 갱신한다.

3. result를반환한다.

// 1 요령 따라서 만든 첫번째 해시 코드
// 31쓰는 이유는, 간단히 해시효과를 높여주기 위함이다. 
// 31 = 홀수이면서 소수 = 곱셈을 시프트연산과 뺄셈으로 대체해 최적화 할 수 있다.
@Override public int hashCode() {
    int result = Short.hashCode(areaCode);
    result = 31 * result + Short.hashCode(prefix); 
    result = 31 * result + Short.hashCode(lineNum);
    return result;
}

// 2 위 Object의 정적팩토리 메서드 hash 사용해 1과 같은 기능을 구현한 다른 코드, 
// 배열을 만들고 오토박싱 과정이 들어 있어 위보단 느릴 수 있다. 
@Override public int hashCode() {
    return Objects.hash(lineNum, prefix, areaCode);
}

// 객체가 주로 해시의 키로 사용될 것 같다면 인스턴스가 만들어질 때 해시코드를 계산해둬야 한다.
// 키로 사용되지 않는 경우라면, 지연 초기화 전략을 사용하자.

// 3 해시코드를 지연 초기화하는 hashcode 메서드
private int hashCode; // 인스턴스 생성시 0 으로 자동 초기화.

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

주의할 점은 성능을 높인답시고 해시코드를 계산할 때 핵심 필드를 생략해서는 안 된다. 그리고 hashCode가 반환하는 값의 생성 규칙을 API 사용자에게 자세히 공표하지 말자. 자바 라이브러리의 많은 클래스에서 hashCode 메서드가 반환하는 정확한 값을 알려준다. 바람직하지 않은 실수지만 바로잡기에는 이미 늦었다.

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

toString의 규약은 "모든 하위 클래스에서 이 메서드를 재정의하라"고 한다.

//멤버에 name, address 멤버 변수가 있다.
Member member1 = new Member("이름1","주소1");

//toString 구현 x -> 16진수로_표시한_해시코드 반환
System.out.println(member1); // com.larrykim.item1120.item11.Member@9e2

//toString 구현 o
System.out.println(member1); // Member{name='1', address='2'}

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

이번 아이템 에서는 clone 메서드를 잘 동작하게끔 해주는 구현 방법과 언제 그렇게 해야 하는지를 알려주고, 가능한 다른 선택지에 관해 논의한다.

// 가변상태에 참조가 없는 클래스를 위한 clone
// 다른 말로 PhoneNumber는 가변상태가 (리스트 같은게) 없다.
@Override public PhoneNumber clone() {
    try {
        return (PhoneNumber) super.clone();
    } catch (CloneNotSupportedException e) {
        throw new AssertionError(); // Can't happen
    }
}

클래스가 가변 객체를 참조하는 순간 재앙으로 돌변한다.

아래 클래스를 복제할 수 있도록 하고 (Cloneable 설정), super.clone의 결과를 그대로 반환한다면 어떻게 될까? size 필드는 올바른 값을 갖겠지만 elements 필드는 (리스트) 원본 Stack 인스턴스와 똑같은 배열을 참조할 것이다.

// 아이템 7 코드 - 스택
public class Stack {
    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; // Eliminate obsolete reference
        return result;
    }
    // Ensure space for at least one more element.
    private void ensureCapacity() {
        if (elements.length == size)
            elements = Arrays.copyOf(elements, 2 * size + 1);
    }
}

clone 메서드는 사실상 생성자와 같은 효과를 낸다. 즉, clone은 원본 객체에 아무런 해를 끼치지 않는 동시에 복제된 객체의 불변식을 보장해야한다.

// 이렇게 바꿔줘야 한다.
@Override public Stack clone() {
    try {
        Stack result = (Stack) super.clone();
        result.elements = elements.clone(); // elements 또한 clone
        return result;
    } catch (CloneNotSupportedException e) {
        throw new AssertionError();
    }
}

참고, 복제할 수 있는 클래스를 만들기 위해 일부 필드에서 final 한정자를 제거해야 할 수도 있다. final 특징 알아보기.

HashTable을 구현해서 확인해보자.

public class HashTable implements Cloneable {
    private Entry[] buckets = new Entry[10];

    private static class Entry {
        final Object key;
        Object value;
        Entry next;

        Entry(Object key, Object value, Entry next) {
            this.key = key;
            this.value = value;
            this.next = next;
        }

        // 방법 1 - 연결리스트
        // 재귀 호출 때문에 리스트의 원소 수만큼 스택 프레임을 소비하여, 
        // 리스트가 길면 스택 오버플로를 일으킬 위험이 있다.
        Entry deepCopy() {
            return new Entry(key, value,
                             next == null ? null : next.deepCopy());
        }

        // 방법 2 - 위 문제를 피해 반복자를 써서 순회하는 방향
        Entry deepCopy() {
            Entry result = new Entry(key, value, next);
            for (Entry p = result; p.next != null; p = p.next)
                p.next = new Entry(p.next.key, p.next.value, p.next.next);
            return result;
        }
    }

    @Override
    public HashTable clone() {
        try {
            HashTable result = (HashTable) super.clone();
            result.buckets = new Entry[buckets.length];
            for (int i = 0; i < buckets.length; i++)
                if (buckets[i] != null)
                    result.buckets[i] = buckets[i].deepCopy();
            return result;
        } catch (CloneNotSupportedException e) {
            throw new AssertionError();
        }
    }
}

Cloneable을 구현하는 모든 클래스는 clone을 재정의해야 한다. 이 메서드는 가장 먼저 supen.clone을 호출한 후 필요한 필드를 전부 적절히 수정한다. 이 말은 그 객체의 내부 ‘깊은 구조’에 숨어 있는 모든 가변 객체를 복사하고, 복제본이 가진 객체 참조 모두가 복사된 객체들을 가리키게 함을 뜻한다. 이러한 내부 복사는 주로 clone을 재귀적으로 호출해 구현하지만 이 방식이 항상 최선인 것은 아니다. 기본 타입 필드와 불변 객체 참조만 갖는 클래스라면 아무 필드도 수정할 필요가 없다. 단, 일련번호나 고유 ID는 비록 기본타입이나 불변일지라도 수정해줘야 한다.

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

// 1 Copy constructor = 변환 생성자 conversion constructor
public Yum(Yum yum) { ... };

// 2 Copy factory = 변환 팩토리 conversion factory
public static Yum newInstance(Yum yum) { ... };

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

equals와 다르게 compareTo는 단순 동치성 비교에 더해 순서까지 비교할 수 있으며, 제네릭하다. Comparable을 구현했다는 것은 그 클래스의 인스턴스들에는 자연적인 순서(natural order)가 있음을 뜻한다. 그래서 Comparable을 구현한 객체 들의 배열은 Arrays.sort(a) 손쉽게 정렬할 수 있다.

검색, 극단값 계산, 자동 정렬되는 컬렉션 관리도 역시 쉽게할 수 있다. 예컨대 다음 프로그램은 명령줄 인수들을 (중복은 제거하고) 알파벳순으로 출력한다.

public class WordList {
    public static void main(String[] args) {
        String[] strings = {"z","b","c","a"};
        Set<String> s = new TreeSet<>();
        Collections.addAll(s,strings);
        System.out.println(s);
    }
}

compareTo와 equals는 항상 일관되지 않는다. 예, BigDicimal을 각각 HashSet과 TreeSet에 넣을 경우 차이가 있다.

// SET은 내부적으로 equals비교를 하영 중복이 못들가는데, BigDecimal은 들어가졌다.
Set<BigDecimal> bigDecimalSet = new HashSet<>();
BigDecimal bd1 = new BigDecimal("1.0");
BigDecimal bd2 = new BigDecimal("1.00");
bigDecimalSet.add(bd1);
bigDecimalSet.add(bd2);
System.out.println(bigDecimalSet); // 1.0, 1.00
-------------------------------------------------------------------------------
//TreeSet에서는 내부적으로 compareTo비교를 하는데, BigDecimal (1.0, 1.00) 허용이 안됬다.
Set<BigDecimal> bigDecimalSet1= new TreeSet<>();
BigDecimal bd1 = new BigDecimal("1.0");
BigDecimal bd2 = new BigDecimal("1.00");
bigDecimalSet1.add(bd1);
bigDecimalSet1.add(bd2);
System.out.println(bigDecimalSet1); // 1.0

CaseInsensitiveString에 compareTo 구현. 자바 7 부터는 정적메서드 compare사용

public class CaseInsensitiveString implements Comparable<CaseInsensitiveString>{
    private String s;
    public CaseInsensitiveString(String s) { this.s = s; }
    @Override
    public int compareTo(CaseInsensitiveString cis) {
        // <, > 비교가 아닌 자바 7 부터는 정적메서드 compare사용
        return String.CASE_INSENSITIVE_ORDER.compare(s,cis.s);
    }
}

PhoneNumber에 compareTo 구현.

public final class PhoneNumber implements Comparable<PhoneNumber> {
    private final short areaCode, prefix, lineNum;

    public PhoneNumber(int areaCode, int prefix, int lineNum) {...}

    private static short rangeCheck(int val, int max, String arg) {...}

    @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 result;
    }
}

자바 8부터 비교자 생성 메서드 Comparator construction method를 사용하면 연쇄 방식으로 비교자를 생성할 수 있게 되었다. 이렇게 사용하자..

public final class PhoneNumber {
    ...
    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);
    }
    ...
}

핵심정리

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