ICloneable <T>がないのはなぜですか？

ジェネリックICloneable<T>が存在しない特別な理由はありますか？

クローンを作成するたびにキャストする必要がない場合は、はるかに快適です。

ICloneableは、結果が深いコピーであるか浅いコピーであるかを指定しないため、現在は不正なAPIと見なされています。これが彼らがこのインターフェースを改善しない理由だと思います。

型指定された複製拡張メソッドを実行できるかもしれませんが、拡張メソッドは元のメソッドよりも優先度が低いため、別の名前が必要になると思います。

アンドレイの回答に加えて、（私は同意する、1） -ときICloneable されて行わ、あなたはまた、公開するための明示的な実装を選択することができClone()、戻り型指定されたオブジェクトを：

public Foo Clone() { /* your code */ }
object ICloneable.Clone() {return Clone();}

もちろん、ジェネリックには2番目の問題がありますICloneable<T>-継承です。

私が持っている場合：

public class Foo {}
public class Bar : Foo {}

そして私は実装しましたICloneable<T>、そして私は実装しICloneable<Foo>ますか？ICloneable<Bar>？すぐに多くの同一のインターフェースの実装を開始します...キャストと比較して...そしてそれは本当にとても悪いですか？

私は質問する必要があります。それを実装する以外に、インターフェイスを正確にどうしますか？インターフェイスは通常、キャストする（つまり、このクラスが 'IBar'をサポートする）か、それを受け取るパラメーターまたはセッター（つまり、 'IBar'を受け取る）がある場合にのみ役立ちます。ICloneableを使用した場合-フレームワーク全体を調べたところ、その実装以外の場所で単一の使用法を見つけることができませんでした。また、それを実装する以外の何かを実行する「現実の世界」での使用法を見つけることができませんでした（アクセスできる〜60,000のアプリで）。

ここで、「クローン可能な」オブジェクトに実装させたいパターンを適用したいだけであれば、それは完全に適切な使用法です。また、「クローニング」が自分にとって何を意味するか（つまり、深いか浅いか）を正確に決定することもできます。ただし、その場合、私たち（BCL）が定義する必要はありません。BCLで抽象化を定義するのは、関係のないライブラリ間でその抽象化として型指定されたインスタンスを交換する必要がある場合のみです。

デビッドキーン（BCLチーム）

「なぜ」という質問は不要だと思います。多くのインターフェース/クラス/などがあります...これは非常に便利ですが、.NET Frameworkuベースライブラリの一部ではありません。

しかし、主にあなた自身でそれを行うことができます。

public interface ICloneable<T> : ICloneable {
    new T Clone();
}

public abstract class CloneableBase<T> : ICloneable<T> where T : CloneableBase<T> {
    public abstract T Clone();
    object ICloneable.Clone() { return this.Clone(); }
}

public abstract class CloneableExBase<T> : CloneableBase<T> where T : CloneableExBase<T> {
    protected abstract T CreateClone();
    protected abstract void FillClone( T clone );
    public override T Clone() {
        T clone = this.CreateClone();
        if ( object.ReferenceEquals( clone, null ) ) { throw new NullReferenceException( "Clone was not created." ); }
        return clone
    }
}

public abstract class PersonBase<T> : CloneableExBase<T> where T : PersonBase<T> {
    public string Name { get; set; }

    protected override void FillClone( T clone ) {
        clone.Name = this.Name;
    }
}

public sealed class Person : PersonBase<Person> {
    protected override Person CreateClone() { return new Person(); }
}

public abstract class EmployeeBase<T> : PersonBase<T> where T : EmployeeBase<T> {
    public string Department { get; set; }

    protected override void FillClone( T clone ) {
        base.FillClone( clone );
        clone.Department = this.Department;
    }
}

public sealed class Employee : EmployeeBase<Employee> {
    protected override Employee CreateClone() { return new Employee(); }
}

必要に応じて、自分でインターフェースを作成するのは非常に簡単です。

public interface ICloneable<T> : ICloneable
        where T : ICloneable<T>
{
    new T Clone();
}

なぜオブジェクトをコピーするのが大変なことかという記事を最近読んだことがありますか？、この質問には追加の分類が必要だと思います。ここでの他の答えは良いアドバイスを提供しますが、それでも答えは完全ではありません-なぜ駄目なのICloneable<T>ですか？

1. 使用法

   したがって、それを実装するクラスがあります。以前は必要なメソッドがありましたがICloneable、今では受け入れるためにジェネリックでなければなりませんICloneable<T>。編集する必要があります。

   次に、オブジェクトかどうかをチェックするメソッドを取得できますis ICloneable。今何？できません。is ICloneable<>コンパイルタイプではオブジェクトのタイプがわからないため、メソッドをジェネリックにすることはできません。最初の本当の問題。

   したがって、ICloneable<T>との両方が必要ですICloneable。前者は後者を実装します。したがって、実装者は- object Clone()との両方のメソッドを実装する必要がありT Clone()ます。いいえ、ありがとうございIEnumerableます。すでにで十分に楽しんでいます。

   すでに指摘したように、継承の複雑さもあります。共分散がこの問題を解決するように見えるかもしれませんが、派生型ICloneable<T>はそれ自体の型を実装する必要がありますが、基本Clone()クラスの-同じシグニチャー（=パラメーター、基本的に）を持つメソッドがすでにあります。新しいクローンメソッドインターフェースを明示的にしても意味がありませんICloneable<T>。作成時に求めていた利点が失われます。したがって、newキーワードを追加します。ただし、基本クラスもオーバーライドする必要があることを忘れないでくださいClone()（すべての派生クラスで実装を統一する必要があります。つまり、すべてのクローンメソッドから同じオブジェクトを返すため、基本クローンメソッドはでなければなりませんvirtual）。しかし、残念ながら、両方overrideとnew同じシグネチャを持つメソッド。最初のキーワードを選択すると、追加時に目標を失うことになりますICloneable<T>。2番目のものを選択すると、インターフェース自体が壊れて、同じことをするはずのメソッドが異なるオブジェクトを返すようになります。

2. ポイント

   あなたICloneable<T>は快適さを求めていますが、快適さはインターフェースが設計されたものではありません、それらの意味はオブジェクトの動作を統一することです（C＃では、外部の動作、たとえばメソッドとプロパティを統一することに限定されますが、彼らの働き）。

   最初の理由でまだ納得がいかない場合は、ICloneable<T>限定的に機能するオブジェクトを作成して、cloneメソッドから返されるタイプを制限できます。ただし、厄介なプログラマはICloneable<T>、Tがそれを実装している型ではない場合でも実装できます。だから、あなたの制限を達成するために、あなたは、一般的なパラメータに素敵な制約を追加することができます：
   public interface ICloneable<T> : ICloneable where T : ICloneable<T>
   確かに、より制限せずに、1つのことをwhereあなたがまだいることを制限することはできません、Tは、インターフェイスを実装しているタイプである（あなたがから派生させることができICloneable<T>、異なる種類のそれを実装しています）。

   ご覧のとおり、この目的を達成することはできませんでした（オリジナルICloneableもこれで失敗します。実装クラスの動作を本当に制限できるインターフェイスはありません）。

ご覧のとおり、これは汎用インターフェースを完全に実装するのが困難であるだけでなく、本当に不要で役に立たないことを証明しています。

しかし、質問に戻ります。あなたが本当に求めているのは、オブジェクトを複製するときの快適さです。それには2つの方法があります。

追加の方法

public class Base : ICloneable
{
    public Base Clone()
    {
        return this.CloneImpl() as Base;
    }

    object ICloneable.Clone()
    {
        return this.CloneImpl();
    }

    protected virtual object CloneImpl()
    {
        return new Base();
    }
}

public class Derived : Base
{
    public new Derived Clone()
    {
        return this.CloneImpl() as Derived;
    }

    protected override object CloneImpl()
    {
        return new Derived();
    }
}

このソリューションは、ユーザーに快適さと意図された動作の両方を提供しますが、実装するには長すぎます。現在の型を返す「快適な」メソッドを使用したくない場合は、単にを使用する方がはるかに簡単public virtual object Clone()です。

それでは、「究極の」ソリューションを見てみましょう。C＃で何が本当に私たちに快適さを与えることを意図していますか？

拡張メソッド！

public class Base : ICloneable
{
    public virtual object Clone()
    {
        return new Base();
    }
}

public class Derived : Base
{
    public override object Clone()
    {
        return new Derived();
    }
}

public static T Copy<T>(this T obj) where T : class, ICloneable
{
    return obj.Clone() as T;
}

現在のCloneメソッドと衝突しないように、Copyという名前が付けられています（コンパイラーは、拡張メソッドよりも、タイプ自体の宣言されたメソッドを優先します）。制約は、（などヌルチェックを必要としない）の速度のためにそこにあります。class

これで作れない理由が明確になればいいのですがICloneable<T>。ただし、実装ICloneableしないことをお勧めします。

質問は非常に古く（この回答を書いてから5年:)、すでに回答されていますが、この記事が質問に非常によく答えていることがわかりましたので、こちらで確認してください

編集：

質問に答える記事からの引用は次のとおりです（記事全体を必ずお読みください。他の興味深いものも含まれています）。

ICloneableについてのいくつかの考察が議論されているブラッド・エイブラムスによる2003年のブログ投稿（Microsoftで採用されていた当時）を指すインターネット上の多くの参照があります。ブログエントリは次のアドレスにあります：Implementing ICloneable。誤解を招くタイトルにもかかわらず、このブログエントリは、主に浅い/深い混乱のために、ICloneableを実装しないことを求めています。記事はまっすぐな提案で終わります。クローン作成メカニズムが必要な場合は、独自のクローン作成方法またはコピー方法を定義し、それが深いコピーか浅いコピーかを明確に文書化するようにしてください。適切なパターンは次のとおりです。public <type> Copy();

大きな問題は、Tを同じクラスに制限できないことです。前の例では、これを防ぐことができます：

interface IClonable<T>
{
    T Clone();
}

class Dog : IClonable<JackRabbit>
{
    //not what you would expect, but possible
    JackRabbit Clone()
    {
        return new JackRabbit();
    }

}

次のようなパラメータ制限が必要です。

interfact IClonable<T> where T : implementing_type

それは非常に良い質問です...自分で作ることもできますが、

interface ICloneable<T> : ICloneable
{
  new T Clone ( );
}

Andreyは、それは悪いAPIと考えられていると言いますが、このインターフェースが廃止されることについては何も聞いていません。そして、それはたくさんのインターフェースを壊します... Cloneメソッドは浅いコピーを実行するべきです。オブジェクトがディープコピーも提供する場合は、オーバーロードされたClone（bool deep）を使用できます。

編集：私がオブジェクトの「クローン」に使用するパターンは、コンストラクターでプロトタイプを渡します。

class C
{
  public C ( C prototype )
  {
    ...
  }
}

これにより、潜在的な冗長コードの実装状況が削除されます。ところで、ICloneableの制限について話していますが、シャロークローンまたはディープクローン、あるいは部分的にシャロー/部分的にディープクローンを実行する必要があるかどうかを決定するのは、オブジェクト自体にありませんか？オブジェクトが意図したとおりに機能する限り、本当に気にする必要がありますか？場合によっては、適切なCloneの実装には、浅い複製と深い複製の両方が含まれることがあります。