Sao chép hàm tạo so với Clone ()

Trong C #, cách ưa thích để thêm chức năng sao chép (sâu) vào một lớp là gì? Có nên thực hiện các constructor sao chép, hoặc xuất phát từ ICloneablevà thực hiện Clone()phương thức?

Ghi chú : Tôi đã viết "sâu" trong ngoặc vì tôi nghĩ nó không liên quan. Rõ ràng những người khác không đồng ý, vì vậy tôi đã hỏi liệu một hàm tạo / toán tử / hàm sao chép có cần phải làm rõ biến thể sao chép mà nó thực hiện không .

Bạn không nên xuất phát từ ICloneable.

Lý do là khi Microsoft thiết kế khung .net, họ không bao giờ chỉ định Clone()phương thức trên ICloneablelà bản sao sâu hay nông, do đó giao diện bị phá vỡ về mặt ngữ nghĩa vì người gọi của bạn sẽ không biết liệu cuộc gọi sẽ nhân bản sâu hay nông.

Thay vào đó, bạn nên xác định riêng của bạn IDeepCloneable(và IShallowCloneable) giao diện với DeepClone()(và ShallowClone()) phương pháp.

Bạn có thể xác định hai giao diện, một giao diện có tham số chung để hỗ trợ nhân bản được gõ mạnh và một không có khả năng nhân bản được gõ yếu khi bạn làm việc với các bộ sưu tập các loại đối tượng có thể nhân bản khác nhau:

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

Mà sau đó bạn sẽ thực hiện như thế này:

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

Nói chung, tôi thích sử dụng các giao diện được mô tả trái ngược với một hàm tạo sao chép, nó giữ cho ý định rất rõ ràng. Một constructor sao chép có thể được coi là một bản sao sâu sắc, nhưng chắc chắn nó không có nhiều ý định rõ ràng như sử dụng giao diện IDeepClonable.

Điều này được thảo luận trong Nguyên tắc thiết kế khung .net và trên blog của Brad Abrams

_{(Tôi cho rằng nếu bạn đang viết một ứng dụng (trái ngược với khung / thư viện) để bạn có thể chắc chắn rằng không ai trong nhóm của bạn sẽ gọi mã của bạn, điều đó không quan trọng lắm và bạn có thể gán ý nghĩa ngữ nghĩa của "deepclone" với giao diện IClonizable .net, nhưng bạn nên đảm bảo rằng điều này được ghi lại rõ ràng và được hiểu rõ trong nhóm của bạn. Cá nhân tôi tuân thủ các nguyên tắc khung.)}

Trong C #, cách ưa thích để thêm chức năng sao chép (sâu) vào một lớp là gì? Có nên thực hiện hàm tạo sao chép, hay xuất phát từ IClonizable và thực hiện phương thức Clone ()?

Vấn đề với ICloneable, như những người khác đã đề cập, nó không chỉ rõ đó là bản sao sâu hay nông, khiến nó thực tế không thể sử dụng được và trong thực tế, hiếm khi được sử dụng. Nó cũng trở lại object, đó là một nỗi đau, vì nó đòi hỏi rất nhiều vai. (Và mặc dù bạn đã đề cập cụ thể đến các lớp trong câu hỏi, việc thực hiện ICloneablemột structmôn quyền anh đòi hỏi.)

Một người lập bản sao cũng bị một trong những vấn đề với IClonizable. Không rõ liệu một nhà xây dựng bản sao đang làm một bản sao sâu hay nông.

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

Tốt nhất nên tạo phương thức DeepClone (). Bằng cách này, ý định là hoàn toàn rõ ràng.

Điều này đặt ra câu hỏi liệu nó nên là một phương thức tĩnh hay cá thể.

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

hoặc là

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

Đôi khi tôi hơi thích phiên bản tĩnh, chỉ vì nhân bản có vẻ như là một cái gì đó đang được thực hiện cho một đối tượng hơn là một cái gì đó mà đối tượng đang làm. Trong cả hai trường hợp, sẽ có những vấn đề cần giải quyết khi nhân bản các đối tượng là một phần của hệ thống phân cấp kế thừa và làm thế nào những vấn đề đó được đưa ra cuối cùng có thể thúc đẩy thiết kế.

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

Tôi khuyên bạn nên sử dụng một hàm tạo sao chép trên một phương thức sao chép chủ yếu vì một phương thức sao chép sẽ ngăn bạn tạo các trường readonlycó thể có nếu bạn đã sử dụng một hàm tạo thay thế.

Nếu bạn yêu cầu nhân bản đa hình, thì bạn có thể thêm một abstracthoặc virtual Clone()phương thức vào lớp cơ sở mà bạn thực hiện bằng một cuộc gọi đến hàm tạo sao chép.

Nếu bạn yêu cầu nhiều hơn một loại bản sao (ví dụ: sâu / nông), bạn có thể chỉ định nó với một tham số trong hàm tạo sao chép, mặc dù theo kinh nghiệm của tôi, tôi thấy rằng thường là một hỗn hợp sao chép sâu và nông là những gì tôi cần.

Ví dụ:

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

Có một lập luận tuyệt vời rằng bạn nên triển khai clone () bằng cách sử dụng hàm tạo sao chép được bảo vệ

Tốt hơn là cung cấp một hàm tạo sao chép được bảo vệ (không công khai) và gọi nó từ phương thức sao chép. Điều này cho chúng ta khả năng ủy thác nhiệm vụ tạo một đối tượng cho một thể hiện của chính lớp đó, do đó cung cấp khả năng mở rộng và cũng có thể tạo các đối tượng một cách an toàn bằng cách sử dụng hàm tạo sao chép được bảo vệ.

Vì vậy, đây không phải là một câu hỏi "so với". Bạn có thể cần cả hai hàm tạo sao chép và giao diện sao chép để thực hiện đúng.

(Mặc dù giao diện công cộng được đề xuất là giao diện Clone () thay vì dựa trên Trình xây dựng.)

Đừng để bị cuốn vào cuộc tranh luận sâu hoặc nông rõ ràng trong các câu trả lời khác. Trong thế giới thực, hầu như luôn luôn có một cái gì đó ở giữa - và dù bằng cách nào, không nên là mối quan tâm của người gọi.

Hợp đồng Clone () chỉ đơn giản là "sẽ không thay đổi khi tôi thay đổi hợp đồng đầu tiên". Bao nhiêu biểu đồ bạn phải sao chép hoặc cách bạn tránh đệ quy vô hạn để thực hiện điều đó không nên quan tâm đến người gọi.

Việc triển khai IClonizable không được khuyến nghị do thực tế là nó không được chỉ định cho dù đó là bản sao sâu hay nông, vì vậy tôi sẽ tìm đến nhà xây dựng hoặc chỉ tự mình thực hiện một cái gì đó. Có thể gọi nó là DeepCopy () để làm cho nó thực sự rõ ràng!

Bạn sẽ gặp vấn đề với các nhà xây dựng sao chép và các lớp trừu tượng. Hãy tưởng tượng bạn muốn làm như sau:

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

Ngay sau khi thực hiện các thao tác trên, bạn bắt đầu muốn sử dụng giao diện hoặc giải quyết triển khai DeepCopy () / IClonizable.Clone ().

Vấn đề với IClonizable là cả ý định và tính nhất quán. Nó không bao giờ rõ ràng cho dù đó là một bản sao sâu hay nông. Do đó, có lẽ nó không bao giờ được sử dụng theo cách này hay cách khác.

Tôi không tìm thấy một nhà xây dựng bản sao công khai để rõ ràng hơn về vấn đề đó.

Điều đó nói rằng, tôi sẽ giới thiệu một hệ thống phương pháp phù hợp với bạn và chuyển tiếp ý định (a'la hơi tự ghi lại tài liệu)

Nếu đối tượng bạn đang cố sao chép là Tuần tự hóa, bạn có thể sao chép nó bằng cách tuần tự hóa nó và giải tuần tự hóa nó. Sau đó, bạn không cần phải viết một hàm tạo sao chép cho mỗi lớp.

Tôi không có quyền truy cập vào mã ngay bây giờ nhưng nó là một cái gì đó như thế này

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
}

Nó phụ thuộc vào ngữ nghĩa sao chép của lớp đang đề cập, mà bạn nên xác định mình là nhà phát triển. Phương pháp chọn thường dựa trên các trường hợp sử dụng dự định của lớp. Có lẽ nó sẽ có ý nghĩa để thực hiện cả hai phương pháp. Nhưng cả hai đều có chung nhược điểm - không rõ chính xác phương pháp sao chép nào họ thực hiện. Điều này cần được nêu rõ trong tài liệu cho lớp học của bạn.

Đối với tôi có:

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

thay vì:

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

nhìn như tuyên bố rõ ràng hơn về ý định.

Tôi nghĩ rằng nên có một mẫu chuẩn cho các đối tượng có thể nhân bản, mặc dù tôi không chắc chính xác mẫu đó phải là gì. Liên quan đến nhân bản, dường như có ba loại lớp:

1. Những người rõ ràng hỗ trợ cho nhân bản sâu
2. Những nơi mà nhân bản thành viên sẽ hoạt động như nhân bản sâu, nhưng không có hoặc không cần hỗ trợ rõ ràng.
3. Những người không thể được nhân bản sâu một cách hữu ích và khi nhân bản thành viên sẽ mang lại kết quả xấu.

Theo như tôi có thể nói, cách duy nhất (ít nhất là trong .net 2.0) để có được một đối tượng mới cùng loại với một đối tượng hiện có là sử dụng MemberwiseClone. Một mô hình đẹp dường như có chức năng "mới" / "Bóng tối" luôn luôn trả về kiểu hiện tại, với định nghĩa luôn là gọi MemberwiseClone và sau đó gọi chương trình con ảo được bảo vệ CleanupClone (gốcObject). Thói quen CleanupCode nên gọi base.Cleanupcode để xử lý các nhu cầu nhân bản của loại cơ sở và sau đó thêm dọn dẹp riêng. Nếu thói quen nhân bản phải sử dụng đối tượng ban đầu, thì nó sẽ phải là typecast, nhưng nếu không thì kiểu truyền hình duy nhất sẽ có trong lệnh gọi MemberwiseClone.

Thật không may, cấp độ thấp nhất của loại (1) ở trên thay vì loại (2) sẽ phải được mã hóa để cho rằng các loại thấp hơn sẽ không cần bất kỳ sự hỗ trợ rõ ràng nào để nhân bản. Tôi không thực sự thấy bất kỳ cách nào xung quanh đó.

Tuy nhiên, tôi nghĩ rằng có một mô hình xác định sẽ tốt hơn không có gì.

Ngẫu nhiên, nếu ai đó biết rằng loại cơ sở của một người hỗ trợ iClonizable, nhưng không biết tên của chức năng mà nó sử dụng, có cách nào để tham chiếu chức năng iClonizable.Clone của loại cơ sở của một người không?

Nếu bạn đọc qua tất cả các câu trả lời và thảo luận thú vị, bạn vẫn có thể tự hỏi làm thế nào bạn sao chép chính xác các thuộc tính - tất cả chúng đều rõ ràng, hoặc có cách nào thanh lịch hơn để làm điều đó? Nếu đó là câu hỏi còn lại của bạn, hãy xem điều này (tại StackOverflow):

Làm thế nào để tôi có thể sao chép sâu các bản sao của các lớp bên thứ 3 bằng cách sử dụng một phương thức mở rộng chung?

Nó mô tả cách thực hiện một phương thức mở rộng CreateCopy()tạo ra một bản sao "sâu" của đối tượng bao gồm tất cả các thuộc tính (mà không phải sao chép thuộc tính theo cách thủ công).