Конструктор копирования против 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 и в блоге Брэда Абрамса.

_{(Я полагаю, если вы пишете приложение (в отличие от фреймворка / библиотеки), поэтому вы можете быть уверены, что никто за пределами вашей команды не будет вызывать ваш код, это не имеет большого значения, и вы можете назначить семантическое значение "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()в свой базовый класс, который вы реализуете с помощью вызова конструктора копирования.

Если вам требуется более одного типа копии (например, глубокая / неглубокая), вы можете указать ее с помощью параметра в конструкторе копирования, хотя по своему опыту я считаю, что обычно мне нужна смесь глубокого и поверхностного копирования.

Пример:

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 (), а не основанный на конструкторе.)

Не зацикливайтесь на явных глубоких или поверхностных аргументах в других ответах. В реальном мире это почти всегда что-то среднее, и в любом случае это не должно вызывать беспокойства у вызывающего абонента.

Контракт 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 заключается как в намерении, так и в последовательности. Никогда не ясно, глубокая это копия или поверхностная. Из-за этого он, вероятно, никогда не использовался только так или иначе.

Я не считаю, что общедоступный конструктор копирования более ясен в этом отношении.

Тем не менее, я бы представил систему методов, которая работает для вас и передает намерение (а'ла несколько самодокументируется)

Если объект, который вы пытаетесь скопировать, является сериализуемым, вы можете клонировать его, сериализовав и десериализуя его. Тогда вам не нужно писать конструктор копирования для каждого класса.

У меня сейчас нет доступа к коду, но это примерно так

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()который создает «глубокую» копию объекта, включая все свойства (без необходимости вручную копировать свойство за свойством).