Introduction

If you are designing a public C# API, the usual advice is not to implement ICloneable. The interface is old, it is ambiguous, and callers cannot tell whether Clone() returns a shallow copy or a deep copy without extra documentation.

What ICloneable actually promises

ICloneable gives you only one member: Clone(). The problem is that the contract does not define the semantics clearly enough for modern library design. A caller sees the method name, but still does not know whether nested objects are copied, shared, or partially rebuilt.

That ambiguity causes real bugs. A shallow copy may look correct until a nested list or reference type is changed in one instance and the other instance changes too. A deep copy may be unexpectedly expensive. Because the interface hides that distinction, it often creates more confusion than value.

This is why many .NET developers treat ICloneable as an implementation detail at most, not as a public promise.

Prefer explicit cloning APIs

A better design is to expose the exact behavior in the API name. A copy constructor, a static factory, or named methods such as DeepCopy() and ShallowCopy() make the semantics obvious.

Here is a simple example using a copy constructor and a clearly named deep copy method:

1using System;
2using System.Collections.Generic;
3
4public sealed class ReportOptions
5{
6    public string Title { get; }
7    public List<string> Columns { get; }
8
9    public ReportOptions(string title, IEnumerable<string> columns)
10    {
11        Title = title;
12        Columns = new List<string>(columns);
13    }
14
15    public ReportOptions(ReportOptions other)
16        : this(other.Title, other.Columns)
17    {
18    }
19
20    public ReportOptions DeepCopy()
21    {
22        return new ReportOptions(this);
23    }
24}
25
26public static class Program
27{
28    public static void Main()
29    {
30        var original = new ReportOptions("Sales", new[] { "Region", "Total" });
31        var copy = original.DeepCopy();
32
33        copy.Columns.Add("Margin");
34
35        Console.WriteLine(original.Columns.Count);
36        Console.WriteLine(copy.Columns.Count);
37    }
38}

The output shows that the two instances no longer share the Columns list. More importantly, the method name tells the caller what to expect.

When implementing ICloneable can still be reasonable

There are cases where implementing it is acceptable. If you control both sides of the code, or you are matching an existing framework pattern, the ambiguity may be manageable. In that situation, document the semantics right next to the type and keep the method behavior stable.

You can also have a type implement ICloneable internally while still steering external callers toward a better API.

1using System;
2
3public sealed class ConnectionSettings : ICloneable
4{
5    public string Host { get; }
6    public int Port { get; }
7
8    public ConnectionSettings(string host, int port)
9    {
10        Host = host;
11        Port = port;
12    }
13
14    public ConnectionSettings(ConnectionSettings other)
15        : this(other.Host, other.Port)
16    {
17    }
18
19    public ConnectionSettings Copy()
20    {
21        return new ConnectionSettings(this);
22    }
23
24    object ICloneable.Clone()
25    {
26        return Copy();
27    }
28}

This pattern is safer than exposing only Clone(), because the public method with the clearer name remains available.

Modern alternatives in C#

For immutable types, records often remove the need for cloning entirely. A record with a with expression can produce a modified copy while preserving readability. For mutable types, copy constructors and named methods are still the most explicit option.

The design principle is straightforward: make copying semantics visible. If a caller must read documentation to know whether a copied object shares state, the API is already too vague.

Common Pitfalls

• Exposing ICloneable in a public API and assuming callers know whether the clone is deep or shallow.
• Returning a shallow copy for a type with mutable nested references and causing aliasing bugs later.
• Using serialization as a default cloning strategy. It is often slower, harder to maintain, and tied to serialization concerns rather than object design.
• Forgetting to copy collections defensively in a so-called deep clone.
• Choosing cloning when immutability or a record type would make copying unnecessary.

Summary

• 'ICloneable is usually not the best public API choice in modern C#.'
• Its main problem is ambiguity: Clone() does not clearly describe copy depth or cost.
• Prefer copy constructors, Copy(), DeepCopy(), or immutable record patterns.
• If you implement ICloneable, document the behavior and keep a clearer public method available.
• Good cloning design is about explicit semantics, not about using a specific legacy interface.