Konstruktor kopiujący kontra Clone ()

W języku C #, jaki jest preferowany sposób dodawania (głębokiej) funkcji kopiowania do klasy? Czy należy implementować konstruktor kopiujący, czy raczej wyprowadzać ICloneablei implementować Clone()metodę?

Uwaga : napisałem „głęboko” w nawiasach, ponieważ uważałem, że to nie ma znaczenia. Najwyraźniej inni się z tym nie zgadzają, więc zapytałem, czy konstruktor / operator / funkcja kopiowania musi wyjaśnić, który wariant kopii implementuje .

Nie powinieneś pochodzić z ICloneable.

Powodem jest to, że kiedy Microsoft zaprojektował framework .net nigdy nie określił, czy Clone()metoda ICloneablepowinna być głębokim, czy płytkim klonem, więc interfejs jest semantycznie zepsuty, ponieważ wywołujący nie będą wiedzieć, czy wywołanie będzie głęboko, czy płytko sklonuje obiekt.

Zamiast tego powinieneś zdefiniować własne IDeepCloneable(i IShallowCloneable) interfejsy z metodami DeepClone()(i ShallowClone()).

Można zdefiniować dwa interfejsy, jeden z parametrem ogólnym obsługującym klonowanie silnie wpisane, a drugi bez zachowania możliwości klonowania słabo typizowanego podczas pracy z kolekcjami różnych typów obiektów, które można klonować:

public interface IDeepCloneable
{
    object DeepClone();
}
public interface IDeepCloneable<T> : IDeepCloneable
{
    T DeepClone();
}

Które następnie zaimplementowałbyś w ten sposób:

public class SampleClass : IDeepCloneable<SampleClass>
{
    public SampleClass DeepClone()
    {
        // Deep clone your object
        return ...;
    }
    object IDeepCloneable.DeepClone()   
    {
        return this.DeepClone();
    }
}

Generalnie wolę używać opisanych interfejsów w przeciwieństwie do konstruktora kopiującego, dzięki czemu cel jest bardzo jasny. Prawdopodobnie zakłada się, że konstruktor kopiujący jest głębokim klonem, ale z pewnością nie jest to tak wyraźny zamiar, jak użycie interfejsu IDeepClonable.

Jest to omówione w wytycznych dotyczących projektowania frameworka .net oraz na blogu Brada Abramsa

_{(Przypuszczam, że jeśli piszesz aplikację (w przeciwieństwie do frameworka / biblioteki), więc możesz być pewien, że nikt spoza Twojego zespołu nie będzie wywoływał Twojego kodu, nie ma to większego znaczenia i możesz przypisać znaczenie semantyczne "deepclone" do interfejsu .net ICloneable, ale powinieneś upewnić się, że jest to dobrze udokumentowane i dobrze zrozumiane w Twoim zespole. Osobiście trzymałbym się wytycznych dotyczących frameworka).}

W języku C #, jaki jest preferowany sposób dodawania (głębokiej) funkcji kopiowania do klasy? Czy należy zaimplementować konstruktor kopiujący, czy raczej wyprowadzić z ICloneable i zaimplementować metodę Clone ()?

Problem ICloneablepolega na tym, jak wspominali inni, że nie precyzuje, czy jest to głęboka, czy płytka kopia, co sprawia, że ​​jest praktycznie bezużyteczna iw praktyce rzadko używana. Wraca również object, co jest uciążliwe, ponieważ wymaga wielu rzutów. (I chociaż wyraźnie wspomniałeś o klasach w pytaniu, implementacja ICloneablena a structwymaga boksu.)

Konstruktor kopii również cierpi na jeden z problemów z ICloneable. Nie jest oczywiste, czy konstruktor kopiujący wykonuje głęboką, czy płytką kopię.

Account clonedAccount = new Account(currentAccount); // Deep or shallow?

Najlepiej byłoby utworzyć metodę DeepClone (). W ten sposób zamiar jest doskonale jasny.

W związku z tym pojawia się pytanie, czy powinna to być metoda statyczna czy instancyjna.

Account clonedAccount = currentAccount.DeepClone();  // instance method

lub

Account clonedAccount = Account.DeepClone(currentAccount); // static method

Nieco wolę czasami wersję statyczną, ponieważ klonowanie wydaje się być czymś, co jest wykonywane na obiekcie, a nie czymś, co robi obiekt. W obu przypadkach będą problemy do rozwiązania podczas klonowania obiektów, które są częścią hierarchii dziedziczenia, a sposób, w jaki te problemy są rozwiązywane, może ostatecznie wpłynąć na projekt.

class CheckingAccount : Account
{
    CheckAuthorizationScheme checkAuthorizationScheme;

    public override Account DeepClone()
    {
        CheckingAccount clone = new CheckingAccount();
        DeepCloneFields(clone);
        return clone;
    }

    protected override void DeepCloneFields(Account clone)
    {
        base.DeepCloneFields(clone);

        ((CheckingAccount)clone).checkAuthorizationScheme = this.checkAuthorizationScheme.DeepClone();
    }
}

Zalecam używanie konstruktora kopiującego readonlyzamiast metody clone przede wszystkim dlatego, że metoda clone uniemożliwi tworzenie pól, które mogłyby powstać, gdyby zamiast tego używałeś konstruktora.

Jeśli potrzebujesz klonowania polimorficznego, możesz dodać metodę abstractlub virtual Clone()do swojej klasy bazowej, którą implementujesz za pomocą wywołania konstruktora kopiującego.

Jeśli potrzebujesz więcej niż jednego rodzaju kopii (np: głębokie / płytkie), możesz określić to za pomocą parametru w konstruktorze kopiowania, chociaż z mojego doświadczenia wynika, że ​​zwykle potrzebuję mieszanki głębokiego i płytkiego kopiowania.

Dawny:

public class BaseType {
   readonly int mBaseField;

   public BaseType(BaseType pSource) =>
      mBaseField = pSource.mBaseField;

   public virtual BaseType Clone() =>
      new BaseType(this);
}

public class SubType : BaseType {
   readonly int mSubField;

   public SubType(SubType pSource)
   : base(pSource) =>
      mSubField = pSource.mSubField;

   public override BaseType Clone() =>
      new SubType(this);
}

Jest świetny argument, że powinieneś zaimplementować clone () używając konstruktora chronionego kopiowania

Lepiej jest zapewnić chroniony (niepubliczny) konstruktor kopiujący i wywołać go z metody clone. Daje nam to możliwość delegowania zadania tworzenia obiektu do instancji samej klasy, zapewniając w ten sposób rozszerzalność, a także bezpieczne tworzenie obiektów przy użyciu konstruktora chronionej kopii.

Nie jest to więc kwestia „przeciw”. Aby zrobić to dobrze, możesz potrzebować zarówno konstruktora kopiującego, jak i interfejsu klonowania.

(Chociaż zalecanym interfejsem publicznym jest interfejs Clone (), a nie oparty na konstruktorze).

Nie daj się wciągnąć w wyraźną, głęboką lub płytką argumentację w innych odpowiedziach. W prawdziwym świecie prawie zawsze jest to coś pośredniego - i tak czy inaczej, nie powinno to być problemem osoby dzwoniącej.

Kontrakt Clone () to po prostu „nie zmieni się, kiedy zmienię pierwszy”. To, ile wykresu musisz skopiować lub jak uniknąć nieskończonej rekurencji, aby tak się stało, nie powinno dotyczyć dzwoniącego.

Wdrażanie ICloneable nie jest zalecane , ponieważ nie jest określone, czy jest to głęboka, czy płytka kopia, więc wybrałbym konstruktora lub po prostu zaimplementował coś samodzielnie. Może nazwij to DeepCopy (), aby było to naprawdę oczywiste!

Napotkasz problemy z konstruktorami kopiującymi i klasami abstrakcyjnymi. Wyobraź sobie, że chcesz wykonać następujące czynności:

abstract class A
{
    public A()
    {
    }

    public A(A ToCopy)
    {
        X = ToCopy.X;
    }
    public int X;
}

class B : A
{
    public B()
    {
    }

    public B(B ToCopy) : base(ToCopy)
    {
        Y = ToCopy.Y;
    }
    public int Y;
}

class C : A
{
    public C()
    {
    }

    public C(C ToCopy)
        : base(ToCopy)
    {
        Z = ToCopy.Z;
    }
    public int Z;
}

class Program
{
    static void Main(string[] args)
    {
        List<A> list = new List<A>();

        B b = new B();
        b.X = 1;
        b.Y = 2;
        list.Add(b);

        C c = new C();
        c.X = 3;
        c.Z = 4;
        list.Add(c);

        List<A> cloneList = new List<A>();

        //Won't work
        //foreach (A a in list)
        //    cloneList.Add(new A(a)); //Not this time batman!

        //Works, but is nasty for anything less contrived than this example.
        foreach (A a in list)
        {
            if(a is B)
                cloneList.Add(new B((B)a));
            if (a is C)
                cloneList.Add(new C((C)a));
        }
    }
}

Zaraz po wykonaniu powyższego zaczynasz żałować, że nie użyłeś interfejsu lub zdecydowałeś się na implementację DeepCopy () / ICloneable.Clone ().

Problem z ICloneable dotyczy zarówno intencji, jak i konsekwencji. Nigdy nie jest jasne, czy jest to głęboka, czy płytka kopia. Z tego powodu prawdopodobnie nigdy nie jest używany tylko w taki czy inny sposób.

Nie widzę publicznego konstruktora kopiującego, który byłby bardziej zrozumiały w tej sprawie.

To powiedziawszy, przedstawiłbym system metod, który działa dla ciebie i przekazuje zamiar (a'la trochę samodokumentujący)

Jeśli obiekt, który próbujesz skopiować, można serializować, możesz go sklonować, serializując go i deserializując. Wtedy nie musisz pisać konstruktora kopiującego dla każdej klasy.

Nie mam teraz dostępu do kodu, ale to jest coś takiego

public object DeepCopy(object source)
{
   // Copy with Binary Serialization if the object supports it
   // If not try copying with XML Serialization
   // If not try copying with Data contract Serailizer, etc
}

Zależy to od semantyki kopiowania danej klasy, którą powinieneś zdefiniować jako programistę. Wybrana metoda jest zwykle oparta na zamierzonych przypadkach użycia klasy. Może będzie miało sens wdrożenie obu metod. Ale oba mają podobną wadę - nie jest do końca jasne, jaką metodę kopiowania stosują. Powinno to być jasno określone w dokumentacji twojej klasy.

Dla mnie posiadający:

// myobj is some transparent proxy object
var state = new ObjectState(myobj.State);

// do something

myobject = GetInstance();
var newState = new ObjectState(myobject.State);

if (!newState.Equals(state))
    throw new Exception();

zamiast:

// myobj is some transparent proxy object
var state = myobj.State.Clone();

// do something

myobject = GetInstance();
var newState = myobject.State.Clone();

if (!newState.Equals(state))
    throw new Exception();

wyglądał jak jaśniejsze określenie intencji.

Myślę, że powinien istnieć standardowy wzorzec dla obiektów, które można klonować, chociaż nie jestem pewien, jaki dokładnie powinien być wzór. Jeśli chodzi o klonowanie, wydaje się, że istnieją trzy rodzaje klas:

1. Te, które wyraźnie wspierają głębokie klonowanie
2. Te, w których klonowanie członków będzie działać jako klonowanie głębokie, ale które nie mają ani nie potrzebują wyraźnego wsparcia.
3. Te, których nie można z pożytkiem głęboko sklonować, a klonowanie oparte na członkach przyniesie złe wyniki.

O ile wiem, jedynym sposobem (przynajmniej w .net 2.0), aby uzyskać nowy obiekt tej samej klasy, co istniejący obiekt, jest użycie MemberwiseClone. Wydawałoby się, że fajnym wzorcem byłoby posiadanie "nowej" / "Shadows" funkcji Clone, która zawsze zwraca obecny typ, którego definicja polega zawsze na wywołaniu MemberwiseClone, a następnie wywołaniu chronionej wirtualnej procedury CleanupClone (originalObject). Procedura CleanupCode powinna wywołać base.Cleanupcode, aby obsłużyć potrzeby klonowania typu podstawowego, a następnie dodać własne czyszczenie. Jeśli procedura klonowania musi używać oryginalnego obiektu, musiałaby to być rzutowanie typu, ale w przeciwnym razie jedyne rzutowanie typów byłoby na wywołaniu MemberwiseClone.

Niestety, najniższy poziom klasy, który był typu (1) powyżej, a nie typu (2), musiałby być zakodowany, aby założyć, że jego niższe typy nie będą wymagały żadnego wyraźnego wsparcia dla klonowania. Naprawdę nie widzę sposobu na obejście tego.

Mimo to myślę, że posiadanie określonego wzoru byłoby lepsze niż nic.

Nawiasem mówiąc, jeśli ktoś wie, że jego typ podstawowy obsługuje iCloneable, ale nie zna nazwy funkcji, której używa, czy istnieje sposób na odwołanie się do funkcji iCloneable.Clone swojego typu podstawowego?

Jeśli przeczytasz wszystkie interesujące odpowiedzi i dyskusje, nadal możesz zadać sobie pytanie, w jaki sposób dokładnie kopiujesz właściwości - wszystkie wyraźnie, czy jest na to bardziej elegancki sposób? Jeśli to jest Twoje pozostałe pytanie, spójrz na to (w StackOverflow):

Jak mogę „głęboko” sklonować właściwości klas innych firm przy użyciu ogólnej metody rozszerzenia?

Opisuje, jak zaimplementować metodę rozszerzenia, CreateCopy()która tworzy „głęboką” kopię obiektu zawierającą wszystkie właściwości (bez konieczności ręcznego kopiowania właściwości według właściwości).