[이펙티브 자바] Item13. clone 재정의는 주의해서 진행하라. (clone 대안)

 

item13. clone 재정의는 주의해서 진행하라. 

[이펙티브 자바] Item13. clone 재정의는 주의해서 진행하라. (Clone규약) (tistory.com)

[이펙티브 자바] Item13. clone 재정의는 주의해서 진행하라. (Clone규약)

-> 첫번째 게시글에서는  clone 규약에 대해서 봤는데 clone 메서드의 규약은 약간 허술한 편이라고 할 수있다. 

x.clone() != x  -> true 
x.clone().getClass() == x.getClass() -> true 
x.clone().equals(x) --> 일반적으론 참이지만 필수는 아님 

그리고 모든 필드가 기본 타입이거나 불변 객체를 참조한다면 이 객체는 Cloneable 인터페이스를 구현하고, clone 메서드를 재정의하면 된다. 

 

[이펙티브 자바] Item13. clone 재정의는 주의해서 진행하라. (가변 객체 clone 정의하는 방법) (tistory.com)

[이펙티브 자바] Item13. clone 재정의는 주의해서 진행하라. (가변 객체 clone 정의하는 방법)

근데 가변 객체에 경우에는 말이 달라진다. 여기서는 위와 같이만 구현해주면 원본과 복사본이 같은 객체를 참조하게 돼서 원본이나 복제본 중 하나를 수정한다면 다른 하나도 수정되어 불변식을 해치게 된다. 

-> 따라서 깊은 복사 deep copy를 해야한다. 

 

@Override
public HashTable clone() { 
    HashTable result = null;
    try {
        result = (HashTable) super.clone();
        result.buckets = new Entry[this.buckets.length]; // clone 용 배열 새로 만들어줌

        for (int i = 0; i < this.buckets.length; i++) {
            if (buckets[i] != null) {
                result.buckets[i] = this.buckets[i].deepCopy();
            }
        }
        return result;

    } catch (CloneNotSupportedException e) {
        throw new AssertionError();
    }
}

이렇게 clone 메서드를 정의하고 나서 주의할 점은 재정의할 수 있는 메서드를 호출하지 않아야 한다는 점이다. 

만약에 clone이 하위 클래스에서 재정의한 메서드를 호출하면 하위 클래스는 복제 과정에서 자신의 상태를 교정할 기회를 잃게 되어 원본과 복제본의 상태가 달라질 가능성이 크다. 

 

 

 

그리고 주의할 점으로는 상속해서 쓰기 위한 클래스 설계 방식 중 어느쪽에서든 상속용 클래스는 Cloneable 을 구현해서는 안된다. 

public abstract class Shape implements Cloneable { // 지금은 굳이 사용한 경우
    private int area;

    public abstract int getArea();
   
    
}

지금은 Cloneable 을 굳이 구현한 경우인데 이렇게 되면 Object를 바로 상속할 때 처럼 Cloneable 구현 여부를 하위클래스에서 선택하도록 해 해당 클래스를 확장하는 프로그래머에게 많은 부담을 준다. 

 

이럴때 해결 방법으로는 

/**
 * 방법 1) 프로그래머에게 부담을 덜기 위해서는 기본 clone() 구현체를 제공하고,
 * Cloneable 구현 여부를 서브 클래스에서 선택할 수 있도록 한다.
 * 서브 클래스가 구현을 안해도 되도록
 * @return
 * @throws CloneNotSupportedException
 */
@Override
protected Object clone() throws CloneNotSupportedException {
    return super.clone();
}

clone 메서드를 상위 클래스에서 미리 구현을 하고, 하위 클래스에서 구현을 안해도 되도록 제공해주는 방법이다. 

 

    /**
     * 방법 2) Cloneable 구현을 아예 막는 방법
     * @return
     * @throws CloneNotSupportedException
     */
    @Override
    protected final Object clone() throws CloneNotSupportedException {
        return new CloneNotSupportedException();
    }

또는 clone을 동작하지 않게 구현해놓고 하위 클래스에서 재정의하지 못하게 할 수도 있다. 

 

public class Square extends Shape
{
   private int length, height;
   
   public Square(int length, int height)
   {
      this.length = length;
      this.height = height;
   }
   
   @Override
   public int getArea()
   {
      return this.length * this.height;
   }
   
   public static void main(String[] args) throws CloneNotSupportedException
   {
      Square square = new Square(10, 2);
      Square clone = (Square) square.clone();
      System.out.println("clone.getArea() = " + clone.getArea());
   }
}

 

이렇게 하면 하위 클래스에서는 clone을 구현하지 않아도 된다. 

 

그리고 또 주의?해야할 점은 Cloneable 을 구현한 쓰레드 안전 클래스를 작성할 때는 clone 메서드 역시 적절하게 동기화 해줘야 한다. 

@Override
public synchronized HashTable clone() { // 멀티쓰레드 환경에서 안전해야 한다면 synchronized까지 붙여줘야함
    HashTable result = null;
    try {
        result = (HashTable) super.clone();
        result.buckets = new Entry[this.buckets.length]; // clone 용 배열 새로 만들어줌

        for (int i = 0; i < this.buckets.length; i++) {
            if (buckets[i] != null) {
                result.buckets[i] = this.buckets[i].deepCopy();
            }
        }
        return result;

    } catch (CloneNotSupportedException e) {
        throw new AssertionError();
    }
}

 

 

 

📚 정리 

정리하자면, Cloneable 을 구현하는 모든 클래스는 clone을 재정의해야 하고, 이때 접근 제한자는 public으로, 반환 타입은 클래스 자신으로 변경해주면 된다. 

그 다음 super.clone()을 호출한 후 필요한 필드를 모두 적절히 수정해주면 된다. (깊은 복사로 모든 가변 객체를 복사하고, 복제본이 가진 객체 참조 모두 복사된 객체들을 가리키게 하면 된다.) 

 

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

-> 복사 생성자란 단순히 자신과 같은 클래스의 인스턴스를 인수로 받는 생성자를 말한다. 

/**
 * clone 대안 - copy 생성자를 만드는 방법
 * @param phoneNumber
 */
public PhoneNumber(PhoneNumber phoneNumber)
{
    this(phoneNumber.areaCode, phoneNumber.prefix, phoneNumber.lineNum);
}

이런식으로 복사 생성자나 이에 변형인 복사 팩터리는 Cloneable/ clone 방식보다 더 나은 점이 많다.

일단 언어 모순적이고 위험천만한 객체 생성 메커니즘(생성자를 쓰지 않는 방식)을 사용하지 않으며, 엉성하게 문서화된 규약에 기대지 않고, 정상적인 final 필드 용법과도 충돌하지 않으면서 불필요한 검사 예외를 던지지 않고, 형변환도 필요하지 않다. 

 

 

public static void main(String[] args)
{
   Set<String> hashSet = new HashSet<>();
   hashSet.add("hyejin");
   hashSet.add("clone");
   System.out.println("hashSet = " + hashSet);
   
   Set<String> treeSet = new TreeSet<>(hashSet);
   
   System.out.println("treeSet = " + treeSet);
}

그리고 복사 생성자와 복사 팩터리는 해당 클래스가 구현한 '인터페이스' 타입으로 인스턴스를 인수로 받을 수 있다. 

관례상 모든 범용 컬렉션 구현체는 Collection이나 Map 타입을 받는 생성자를 제공한다. 

이를 이용하면 클라이언트는 원본의 구현 타입에 얽매이지 않으면서도 복제본의 타입을 적절하게 선택할 수 있다. 

위의 예시처럼 HashSet 객체를 TreeSet 타입으로 복제할 수 있다. 

 

 

 

👩‍💻 결론을 말하자면? Cloneable은 지금까지 봐온걸 생각해보면 주의할 점도 많고, 애매모호한 점도 있고 해서 Cloneable을 확장해서는 안되고, 새로운 클래스도 이를 구현하는 것보다는 복사 생성자나 복사 팩터리를 허용하는 것이 더 낫다.