clone () 대 복사 생성자 대 팩토리 메서드?

clone () 대 복사 생성자 대 팩토리 메서드?

---

Java에서 clone () 구현에 대한 빠른 Google을 수행했으며 http://www.javapractices.com/topic/TopicAction.do?Id=71을 찾았습니다.

다음과 같은 주석이 있습니다.

복사 생성자와 정적 팩토리 메소드는 복제에 대한 대안을 제공하며 구현하기가 훨씬 쉽습니다.

내가 원하는 것은 깊은 사본을 만드는 것입니다. clone ()을 구현하는 것은 많은 의미가있는 것 같지만, 구글 순위가 높은이 기사는 저를 조금 두렵게 만듭니다.

내가 발견 한 문제는 다음과 같습니다.

복사 생성자는 Generics에서 작동하지 않습니다.

다음은 컴파일되지 않는 의사 코드입니다.

public class MyClass<T>{
   ..
   public void copyData(T data){
       T copy=new T(data);//This isn't going to work.    
   }
   ..
}

샘플 1 : 제네릭 클래스에서 복사 생성자 사용.

팩토리 메서드에는 표준 이름이 없습니다.

재사용 가능한 코드를위한 인터페이스를 갖는 것은 매우 좋습니다.

public class MyClass<T>{
    ..
    public void copyData(T data){
        T copy=data.clone();//Throws an exception if the input was not cloneable
    }
    ..
}

샘플 2 : 제네릭 클래스에서 clone () 사용.

복제가 정적 메서드가 아니라는 것을 알았지 만 보호 된 모든 필드의 전체 복사본을 만들 필요는 없습니까? clone ()을 구현할 때 복제 불가능한 하위 클래스에서 예외를 던지는 추가 노력은 나에게 사소한 것 같습니다.

내가 뭔가를 놓치고 있습니까? 모든 통찰력을 주시면 감사하겠습니다.

---

기본적으로 클론이 손상되었습니다 . 제네릭으로 쉽게 작동하는 것은 없습니다. 다음과 같은 것이있는 경우 (요점을 파악하기 위해 단축) :

public class SomeClass<T extends Copyable> {


    public T copy(T object) {
        return (T) object.copy();
    }
}

interface Copyable {
    Copyable copy();
}

그런 다음 컴파일러 경고로 작업을 완료 할 수 있습니다. 제네릭은 런타임에 지워지기 때문에 복사를 수행하는 작업에는 캐스트를 생성하는 컴파일러 경고가 표시됩니다. 이 경우 피할 수 없습니다. . 어떤 경우에는 피할 수 있지만 (감사합니다, kb304) 전부는 아닙니다. 인터페이스를 구현하는 하위 클래스 또는 알 수없는 클래스를 지원해야하는 경우를 고려하십시오 (예 : 동일한 클래스를 생성하지 않아도되는 복사 가능 컬렉션을 반복하는 경우).

---

빌더 패턴도 있습니다. 자세한 내용은 효과적인 Java를 참조하십시오.

나는 당신의 평가를 이해하지 못합니다. 복사 생성자에서 유형을 완전히 알고 있는데 왜 제네릭을 사용해야합니까?

public class C {
   public int value;
   public C() { }
   public C(C other) {
     value = other.value;
   }
}

비슷한 질문이 최근에 있었다 여기 .

public class G<T> {
   public T value;
   public G() { }
   public G(G<? extends T> other) {
     value = other.value;
   }
}

실행 가능한 샘플 :

public class GenTest {
    public interface Copyable<T> {
        T copy();
    }
    public static <T extends Copyable<T>> T copy(T object) {
        return object.copy();
    }
    public static class G<T> implements Copyable<G<T>> {
        public T value;
        public G() {
        }
        public G(G<? extends T> other) {
            value = other.value;
        }
        @Override
        public G<T> copy() {
            return new G<T>(this);
        }
    }
    public static void main(String[] args) {
        G<Integer> g = new G<Integer>();
        g.value = 1;
        G<Integer> f = g.copy();
        g.value = 2;
        G<Integer> h = copy(g);
        g.value = 3;
        System.out.printf("f: %s%n", f.value);
        System.out.printf("g: %s%n", g.value);
        System.out.printf("h: %s%n", h.value);
    }
}

---

Java에는 C ++와 동일한 의미의 복사 생성자가 없습니다.

인수와 동일한 유형의 객체를 취하는 생성자를 가질 수 있지만이를 지원하는 클래스는 거의 없습니다. (클론을 지원하는 수 미만)

일반 복제의 경우 클래스의 새 인스턴스를 만들고 반사를 사용하여 원본 (얕은 복사본)에서 필드를 복사하는 도우미 메서드가 있습니다 (실제로는 반사와 비슷하지만 더 빠름).

전체 복사의 경우 간단한 방법은 개체를 직렬화하고 역 직렬화하는 것입니다.

BTW : 내 제안은 변경 불가능한 개체를 사용하는 것입니다. 그러면 복제 할 필요가 없습니다. ;)

---

Yishai 답변이 개선되어 다음 코드로 경고가 표시되지 않을 수 있다고 생각합니다.

public class SomeClass<T extends Copyable<T>> {

    public T copy(T object) {
        return object.copy();
    }
}

interface Copyable<T> {
    T copy();
}

이렇게하면 Copyable 인터페이스를 구현해야하는 클래스는 다음과 같아야합니다.

public class MyClass implements Copyable<MyClass> {

    @Override
    public MyClass copy() {
        // copy implementation
        ...
    }

}

---

다음은 많은 개발자가 사용하지 않는 몇 가지 단점입니다. Object.clone()

1. Using Object.clone() method requires us to add lots of syntax to our code like implement Cloneable interface, define clone() method and handle CloneNotSupportedException and finally call to Object.clone() and cast it our object.
2. Cloneable interface lacks clone() method, it is a marker interface and doesn’t have any method in it, and still we need to implement it just to tell JVM that we can perform clone() on our object.
3. Object.clone() is protected so we have to provide our own clone() and indirectly call Object.clone() from it.
4. We don’t have any control over object construction because Object.clone() doesn’t invoke any constructor.
5. If we are writing clone() method in a child class e.g. Person then all of its superclasses should define clone() method in them or inherit it from another parent class otherwise super.clone() chain will fail.
6. Object.clone() support only shallow copy, so reference fields of our newly cloned object will still hold objects which fields of our original object was holding. In order to overcome this, we need to implement clone() in every class who’s reference our class is holding and then clone them separately in our clone() method like in below example.
7. We can not manipulate final fields in Object.clone() because final fields can only be changed through constructors. In our case, if we want every Person object to be unique by id, we will get the duplicate object if we use Object.clone() because Object.clone() will not call the constructor and final id field can’t be modified from Person.clone().

Copy constructors are better than Object.clone() because they

1. Don’t force us to implement any interface or throw any exception but we can surely do it if it is required.
2. Don’t require any casts.
3. Don’t require us to depend on an unknown object creation mechanism.
4. Don’t require parent class to follow any contract or implement anything.
5. Allow us modify final fields.
6. Allow us to have complete control over object creation, we can write our initialization logic in it.

Read more on Java Cloning - Copy Constructor versus Cloning

---

One pattern that may work for you is bean-level copying. Basically you use a no-arg constructor and call various setters to provide the data. You can even use the various bean property libraries to set the properties relatively easily. This isn't the same as doing a clone() but for many practical purposes it's fine.

---

Usually, clone() works in tandem with a protected copy constructor. This is done because clone(), unlike a constructor, can be virtual.

In a class body for Derived from a super class Base we have

class Derived extends Base {
}

So, at its most simplistic, you would add to this a virtual copy constructor with the clone(). (In C++, Joshi recommends clone as the virtual copy constructor.)

protected Derived() {
    super();
}

protected Object clone() throws CloneNotSupportedException {
    return new Derived();
}

It gets more complicated if you want to call super.clone() as is recommended and you have to add these members to the class, you can try this

final String name;
Address address;

/// This protected copy constructor - only constructs the object from super-class and
/// sets the final in the object for the derived class.
protected Derived(Base base, String name) {
   super(base);
   this.name = name;
}

protected Object clone() throws CloneNotSupportedException {
    Derived that = new Derived(super.clone(), this.name);
    that.address = (Address) this.address.clone();
}

Now, if an execution, you got

Base base = (Base) new Derived("name");

and you then did

Base clone = (Base) base.clone();

this would invoke, clone() in the Derived class (the one above), this would invoke super.clone() - which may or may not be implemented, but you're advised to call it. The implementation then passes output of super.clone() to a protected copy constructor that takes a Base and you pass any final members to it.

That copy constructor then invokes the copy constructor of the super-class (if you know that it has one), and sets the finals.

When you come back to the clone() method, you set any non-final members.

Astute readers will notice that if you have a copy-constructor in the Base, it will be called by super.clone() - and will be called again when you invoke the super-constructor in the protected constructor, so you may be calling the super copy-constructor twice. Hopefully, if it is locking resources, it will know that.

---

The Cloneable interface is broken, in the sense that it is useless but clone works well and can lead to better performance for big objects - 8 fields and more, but it will then fail the escape analysis. so preferable to use copy constructor most of the time. Using clone on array is faster than Arrays.copyOf because the length is guaranteed to be the same.

more details here https://arnaudroger.github.io/blog/2017/07/17/deep-dive-clone-vs-copy.html

---

If one is not 100% aware of all the quirks of clone(), then I would advise to stay away from it. I would not say that clone() broken. I would say: use it only when you are entirely sure it is your best option. A copy constructor (or factory method, that doesn't really matter I think) is easy to write (maybe lengthy, but easy), it only copies what you want to be copied, and copies the way you want things to be copied. You can trim it to your exact needs.

Plus: it's easy to debug what happens when you call your copy constructor / factory method.

And clone() does not create a "deep" copy of your object out of the box, assuming you mean that not only the references (e.g. to a Collection) are copied over. But read more about deep and shallow here: Deep copy, shallow copy, clone

---

What you are missing is that clone creates shallow copies by default and convention, and that making it create deep copies is, in general, not feasible.

The problem is that you cannot really create deep copies of cyclic object graphs, without being able to keep track what objects have been visited. clone() does not provide such tracking (as that would have to be a parameter to .clone()), and thus only creates shallow copies.

Even if your own object invokes .clone for all of its members, it still won't be a deep copy.

참고URL : https://stackoverflow.com/questions/1106102/clone-vs-copy-constructor-vs-factory-method