Конструктор копіювання проти Clone ()

У C #, який є кращим способом додати (глибоку) функцію копіювання до класу? Чи варто реалізовувати конструктор копій, а точніше випливати з ICloneableта застосовувати Clone()метод?

Зауваження : Я написав "глибоко" в дужках, тому що вважав це неактуальним. Мабуть, інші не погоджуються, тому я запитав, чи потрібно конструктору / оператору / функції копію зрозуміти, який варіант копіювання він реалізує .

Ви не повинні виходити з цього ICloneable.

Причина полягає в тому, що коли Microsoft розробляла рамку .net, вони ніколи не вказували, чи повинен Clone()метод ICloneableбути глибоким або дрібним клоном, таким чином інтерфейс семантично порушений, оскільки ваші абоненти не знають, чи буде виклик глибоким чи дрібним клонуванням об'єкта.

Натомість слід визначити власні IDeepCloneable(і IShallowCloneable) інтерфейси методами DeepClone()(і ShallowClone()).

Ви можете визначити два інтерфейси, один із загальним параметром для підтримки сильно набраного клонування та один без збереження слабо набраної здатності клонування, коли ви працюєте з колекціями різних типів об'єктів, що підлягають клонуванню:

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

Що б ви потім реалізували так:

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

Як правило, я віддаю перевагу використанню описаних інтерфейсів на відміну від конструктора копій, але це має чіткий намір. Конструктор копій, мабуть, вважатиметься глибоким клоном, але це, звичайно, не стільки чіткий намір, як використання інтерфейсу IDeepClonable.

Про це йдеться у .net Framework Design Design Guidelines та у блозі Бреда Абрамса

_{(Я думаю, якщо ви пишете заявку (на відміну від фреймворку / бібліотеки), тож ви можете бути впевнені, що ніхто за межами вашої команди не подзвонить ваш код, це не має великого значення, і ви можете призначити смислове значення "deepclone" інтерфейсу .net ICloneable, але ви повинні переконатися, що це добре задокументовано та добре зрозуміло у вашій команді. Особисто я б дотримувався рамкових рекомендацій.)}

У C #, який є кращим способом додати (глибоку) функцію копіювання до класу? Чи слід реалізувати конструктор копій, а точніше випливати з ICloneable та реалізувати метод Clone ()?

Як ICloneableзазначили інші, проблема полягає в тому, що вона не вказує, чи це глибока чи неглибока копія, що робить її практично невикористаною і, на практиці, рідко використовується. Він також повертається object, що є болем, оскільки вимагає багато кастингу. (І хоч ви спеціально згадали класи у запитанні, впроваджуючи ICloneableна них structпотрібно бокс.)

Конструктор копій також страждає від однієї з проблем із ICloneable. Не очевидно, чи конструктор копій робить глибоку чи дрібну копію.

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

Найкраще було б створити метод DeepClone (). Таким чином наміри цілком зрозумілі.

Тут виникає питання, чи повинен це бути статичний або екземплярний метод.

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

або

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

Я дещо віддаю перевагу статичній версії іноді, просто тому, що клонування здається чимось, що робиться об’єкту, а не тим, що робить об'єкт. У будь-якому випадку виникають проблеми, з якими потрібно вирішувати питання щодо клонування об'єктів, які є частиною ієрархії спадкування, і те, як ці проблеми дельтуються, може врешті-решт керувати дизайном.

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

Я рекомендую використовувати конструктор копій над методом клонування насамперед тому, що метод клонування не дозволить вам робити поля, readonlyякі могли бути, якби ви використовували конструктор замість цього.

Якщо вам потрібне поліморфне клонування, ви можете додати до базового класу abstractабо virtual Clone()метод, який ви реалізуєте, за допомогою виклику до конструктора копій.

Якщо вам потрібна більше одного типу копії (наприклад: deep / неглибока), ви можете вказати її за допомогою параметра в конструкторі копій, хоча, на моєму досвіді, я вважаю, що зазвичай потрібна суміш глибокої та дрібної копіювання.

Наприклад:

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

Є чудовий аргумент, що вам слід реалізувати clone () за допомогою захищеного конструктора копій

Краще забезпечити захищений (непублічний) конструктор копій і викликати це методом клонування. Це дає нам можливість делегувати завдання створення об'єкта до екземпляра самого класу, забезпечуючи таким чином розширюваність, а також безпечно створюючи об'єкти за допомогою захищеного конструктора копій.

Тож це не питання "проти". Можливо, вам знадобляться як конструктори копій, так і інтерфейс клонів, щоб зробити це правильно.

(Хоча рекомендований загальнодоступний інтерфейс - це інтерфейс Clone (), а не на основі конструктора.)

Не зациклюйтеся на явному глибокому чи мілкому аргументі в інших відповідях. У реальному світі це майже завжди є щось середнє - і в будь-якому випадку не повинно бути проблемою абонента.

Договір Clone () просто "не зміниться, коли я зміню перший". Яка частина графіка вам доведеться скопіювати або як уникнути нескінченних рекурсій, щоб це сталося, не повинно стосуватися абонента.

Реалізація ICloneable не рекомендується через те, що не вказано, чи є це глибока чи неглибока копія, тому я б пішов на конструктор чи просто щось реалізував сам. Можливо, назвіть це DeepCopy (), щоб зробити це справді очевидним!

Ви зіткнетеся з проблемами з конструкторами копій та абстрактними класами. Уявіть, що ви хочете зробити наступне:

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

Одразу після цього, ви починаєте бажати, щоб ви або використовували інтерфейс, або влаштувались на реалізацію DeepCopy () / ICloneable.Clone ().

Проблема з ICloneable - це і наміри, і послідовність. Ніколи не ясно, чи це глибока чи неглибока копія. Через це він, ймовірно, ніколи не використовується лише тим чи іншим чином.

Я не вважаю, що громадський конструктор копій є більш чітким з цього приводу.

З цього приводу я запровадив систему методів, яка працює для вас і ретранслирує наміри (дещо самодокументування)

Якщо об’єкт, який ви намагаєтесь скопіювати, є Serializable, ви можете його клонувати, серіалізуючи його та десеріалізуючи. Тоді вам не потрібно писати конструктор копій для кожного класу.

Зараз у мене немає доступу до коду, але це щось подібне

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
}

Це залежить від семантики копіювання відповідного класу, яку слід визначити як розробника. Обраний метод, як правило, базується на передбачуваних випадках використання класу. Можливо, буде сенс реалізувати обидва методи. Але обидва поділяють подібний недолік - не зовсім зрозуміло, який метод копіювання вони реалізують. Це має бути чітко зазначено в документації для вашого класу.

Для мене:

// 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();

замість:

// 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();

виглядав як чіткіша заява про наміри.

Я думаю, що має бути стандартний зразок для об'єктів, що підлягають клонуванню, хоча я не впевнений, яким саме повинен бути шаблон. Що стосується клонування, то, здається, існує три типи класів:

1. Ті, які явно підтримують глибоке клонування
2. Ті, де клонування в рамках членів буде працювати як глибоке клонування, але які ні мають, ні потребують явної підтримки.
3. Ті, які не можуть бути корисно глибоко клоновані, і де клонування за допомогою членів дасть погані результати.

Наскільки я можу сказати, єдиний спосіб (принаймні в .net 2.0) отримати новий об’єкт того ж класу, що і існуючий об'єкт, - це використовувати MemberwiseClone. Приємним шаблоном, здавалося б, є функція "новий" / "Тіні" Clone, яка завжди повертає поточний тип, визначення якого завжди викликає MemberwiseClone, а потім викликає захищену віртуальну підпрограму CleanupClone (originalObject). Програма CleanupCode повинна викликати base.Cleanupcode, щоб обробити потреби в клонуванні базового типу, а потім додати власну очистку. Якщо в рутинному режимі клонування потрібно використовувати оригінальний об'єкт, його потрібно було б набрати на клавіатурі, але в іншому випадку єдиний набір клавіш був би при виклику MemberwiseClone.

На жаль, найнижчий рівень класу, який був вище (1), а не тип (2), повинен бути кодований, щоб припустити, що його нижчі типи не потребують явної підтримки для клонування. Я насправді цього не бачу.

Все-таки я думаю, що мати визначений зразок було б краще, ніж нічого.

Між іншим, якщо хтось знає, що базовий тип підтримує iCloneable, але не знає імені функції, яку він використовує, чи є спосіб посилання на функцію iCloneable.Clone базового типу?

Якщо ви прочитаєте всі цікаві відповіді та дискусії, то все-таки можете запитати себе, як саме ви копіюєте властивості - усі вони явно, чи є більш елегантний спосіб зробити це? Якщо це ваше залишкове питання, погляньте на це (на StackOverflow):

Як я можу "глибоко" клонувати властивості класів сторонніх осіб, використовуючи загальний метод розширення?

Він описує, як реалізувати метод розширення, CreateCopy()який створює "глибоку" копію об'єкта, включаючи всі властивості (без необхідності копіювати властивість за властивістю вручну).