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

📍상황

• Cloneable은 복제해도 되는 클래스임을 명시하는 용도인 mixin 인터페이스지만, 아쉽게도 의도한 목적을 제대로 이루지 못했음
  • clone 메서드가 선언된 곳이 Cloneable이 아닌 Object이고, protected로 선언됨 --> Cloneable을 구현하는 것만으로는 외부 객체에서 clone 메서드를 호출할 수 없음
  • 리플렉션을 사용하면 가능하지만, 100% 성공하는 것은 아님 --> 해당 객체가 접근이 허용된 clone 메서드를 제공한다는 보장이 없기 때문임
• 하지만 Cloneable 방식은 널리 쓰이고 있어 잘 알아두는 것이 좋음

 

이번 아이템에서 다룰 내용 

• clone 메서드를 잘 동작하게끔 해주는 구현 방법
• 언제 재정의해서 사용해야 하는지, 가능한 다른 선택지는 무엇인지

 

📍방법

<사전 지식>

Cloneable 인터페이스의 역할

• 해당 인터페이스에는 아무런 메서드도 정의되어 있지 않음
• Object의 protected 메서드인 clone의 동작 방식을 결정함
• Cloneable을 구현한 클래스의 인스턴스에서 clone을 호출하면 그 객체의 필드들을 하나하나 복사한 객체를 반환하고, 그렇지 않은 클래스의 인스턴스에서 호출하면 CloneNotSupportedException을 던짐
• Cloneable의 경우에는 상위 클래스에 정의된 protected 메서드의 동작 방식을 변경한 것임
  • 이는 인터페이스를 이례적으로 사용한 예이니 따라 하지 말자

 

clone 메서드의 일반 규약

 

<제대로 동작하게끔 하는 구현 방법>

1) 가변 객체를 참조하지 않는 클래스

코드 13-1 가변 상태를 참조하지 않는 클래스용 clone 메서드

@Override
public PhoneNumber clone() {
    try {
    	return (PhoneNumber) super.clone();
    } catch (CloneNotSupportedException e) {
    	throw new AssertionError();
    }
}

• super.clone을 호출함
  • 이를 통해 얻은 객체는 원본의 완벽한 복제본임
  • 클래스에 정의된 모든 필드는 원본 필드와 똑같은 값을 갖음
  • 모든 필드가 기본 타입이거나 불변 객체를 참조한다면 이 객체는 완벽히 우리가 원하는 상태임
• 해당 메서드가 동작하게 하려면 PhoneNumber 클래스 선언에 Cloneable을 구현해야 함

 

2) 가변 객체를 참조하는 클래스

예시 - Stack 클래스

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];
    }
    
    ...
}

• clone 메서드가 단순히 super.clone의 결과를 그대로 반환한다면?
  • 반환된 Stack 인스턴스의 size 필드는 올바른 값을 가지지만, elements 필드는 원본 Stack 인스턴스와 똑같은 배열을 참조함
  • 원본이나 복제본 중 하나를 수정하면 다른 하나도 수정되어 불변식을 해침
  • 따라서 프로그램이 이상하게 동작하거나 NullPointerException을 던질 것임
• clone 메서드는 사실상 생성자와 같은 효과를 냄
  • 즉, clone은 원본 객체에 아무런 해를 끼치지 않는 동시에 복제된 객체의 불변식을 보장해야 함
  • 따라서 Stack의 clone 메서드가 제대로 동작하려면 스택 내부 정보를 복사해야 함

 

a) 참조 객체의 내부 정보까지 복사하려면 어떻게 해야할까?

코드 13-2 가변 상태를 참조하는 클래스용 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을 재귀적으로 호출함
• 배열의 clone
  • 런타임과 컴파일타임 타입 모두 원본 배열과 똑같은 배열을 반환함
  • 따라서 배열을 복제할 때는 배열의 clone 메서드를 사용하라고 권장함 --> 배열은 clone 기능을 제대로 사용하는 유일한 예
• 적용하지 못하는 경우
  • elements 필드가 final인 경우 위의 방식은 동작하지 않음 (final 필드에는 새로운 값을 할당할 수 없기 때문)
  • 이는 '가변 객체를 참조하는 필드는 final로 선언하라'는 일반 용법과 충돌함
    • 복제 가능한 클래스를 만들기 위해 일부 필드에서 final 한정자를 제거해야 할 수도 있음

 

b) clone을 재귀적으로 호출하는 것만으로 충분하지 않은 경우는 어떻게 해야할까?

예시 - HashTable

• 해시테이블 내부는 버킷들의 배열이고, 각 버킷은 키-값 쌍을 담는 연결리스트의 첫 번째 엔트리를 참조함

public class HashTable implements Cloneable {
    private Entry[] buckets = ...;
    
    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;
        }
    }
    
    ...
}

 

코드 13-3 잘못된 clone 메서드 - 가변 상태를 공유함

@Override
public HashTable clone() {
    try {
    	HashTable result = (HashTable) super.clone();
        result.buckets = buckets.clone(); //배열 복사
        return result;
    } catch (CloneNotSupportedException e) {
    	throw new AssertionError();
    }
}

 

• 복제본은 자신만의 버킷 배열을 가지지만, 이 배열은 원본과 같은 연결 리스트를 참조하여 원본과 복제본 모두 예기치 않게 동작할 가능성이 생김

 

다음은 일반적인 해법임

코드 13-4 복잡한 가변 상태를 갖는 클래스용 재귀적 clone 메서드

public class HashTable implements Cloneable {
    private Entry[] buckets = ...;
    
    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;
        }
        
        //해당 엔트리가 가리키는 연결 리스트를 재귀적으로 복사
        Entry deepCopy() {
        	return new Entry(key, value,
            	next == null ? null : next.deepCopy());
        }
    }
    
    @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();
        }
    }
    
    ...
}

• private 클래스인 HashTable.Entry에 깊은복사를 추가함
• HashTable의 clone 메서드는
  1. 적절한 크기의 새로운 버킷 배열 할당
  2. 원래의 버킷 배열을 순회하며 비지 않은 각 버킷에 대해 깊은복사를 수행함
• 단점
  • 재귀 호출로 리스트이 원소 수만큼 스택 프레임을 소비함
  • 리스트가 길면 스택 오버플로우를 일으킬 위험이 있음
  • 이 문제를 피하려면 deepCopy를 재귀 호출 대신 반복자를 써서 순회하는 방향으로 수정해야 함

 

코드 13-5 엔트리 자신이 가리키는 연결 리스트를 반복적으로 복사함

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

 

c) 마지막 방법

• super.clone을 호출하여 얻은 객체의 모든 필드를 초기 상태로 설정한 후, 원본 객체의 상태를 다시 생성하는 고수준 메서드들을 호출함
• 예시
  • HashTable 예를 보면, buckets 필드를 새로운 버킷 배열로 초기화함
  • 원본 테이블에 담긴 모든 키-값 쌍 각각에 대해 복제본 테이블의 put(key, value) 메서드를 호출해 둘의 내용이 같게 해주면 됨
• 특징
  • Cloneable 아키텍처의 기초가 되는 필드 단위 객체 복사를 우회하기 때문에 전체 Cloneable 아키텍처와는 어울리지 않는 방식임

 

주의사항

• 생성자에서는 오버라이딩 할 수 있는 메서드를 호출하지 않아야 함
• 상속용 클래스는 Cloneable을 구현하지 않는 것이 좋음 - 예시
• Cloneable을 구현한 thread-safe한 클래스를 작성할 때는 clone 메서드 역시 동기화해줘야 함

 

<clone 대신 권장하는 방법>

• 복사 생성자와 복사 팩터리를 사용한 더 나은 객체 복사 방식을 제공할 수 있음
  • 복사 생성자?
    • 단순히 자신과 같은 클래스의 인스턴스를 인수로 받는 생성자를 말함

 

코드 13-7 복사 생성자

public Yum(Yum yum) { ... }

코드 13-8 복사 팩터리

public static Yum newInstance(Yum yum) { ... }

 

• 위와 같은 인터페이스 기반 복사 생성자와 복사 팩터리를 '변환 생성자'와 '변환 팩터리' 라고 함
• 클라이언트는 원본의 구현 타입에 얽매이지 않고 복제본의 타입을 직접 선택할 수 있음 

 

📍핵심 정리

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

 

읽어볼 것

• https://www.artima.com/articles/josh-bloch-on-design