ICloneableメソッドを継承して実装する必要がある理由を説明してもらえますClone()か?
ディープ コピーを実行したい場合、メソッドを実装することはできませんか? としましょうMyClone()か?
から継承する必要があるのはなぜICloneableですか? 利点は何ですか?コードを「読みやすく」するだけの問題ですか?
ICloneableメソッドを継承して実装する必要がある理由を説明してもらえますClone()か?
ディープ コピーを実行したい場合、メソッドを実装することはできませんか? としましょうMyClone()か?
から継承する必要があるのはなぜICloneableですか? 利点は何ですか?コードを「読みやすく」するだけの問題ですか?
すべきではありません。メソッドが "深い" または "浅い" クローンを実行するICloneableかどうかをインターフェイスから明確に示すことができないため、Microsoft は実装しないことをお勧めします。Clone
詳細については、2003 年 (!) にBrad Abrams が投稿したこのブログ記事を参照してください。
ICloneableインターフェース自体はあまり役に立ちません。つまり、オブジェクトについて他に何も知らなくても、オブジェクトが複製可能であることを知っておくと便利な状況はあまりありません。IEnumerableこれは、egまたはIDisposable;とは非常に異なる状況です。IEnumerableを列挙する方法以外は何も知らずに を受け入れると便利な状況がたくさんあります。
一方、他のICloneable制約とともに一般的な制約として適用すると便利な場合があります。たとえば、基本クラスは多数の派生物を有効にサポートする場合があり、そのうちのいくつかは有用に複製でき、一部は複製できません。基本型自体がパブリック クローニング インターフェイスを公開している場合、クローンを作成できなかった派生型は、Liskov Substitution Principle に違反します。この問題を回避する方法は、基本型で Protected メソッドを使用した複製をサポートし、派生型が適切と思われる公開複製インターフェイスを実装できるようにすることです。
それが達成されると、ある型のオブジェクトを受け取りたいが、WonderfulBaseそれを複製できる必要があるメソッドは、複製をサポートする WonderfulBase オブジェクトを受け入れるようにコーディングできます (基本型とICloneable制約を持つジェネリック型パラメーターを使用) 。 . ICloneableインターフェイス自体はディープ クローニングまたはシャロー クローニングを示すわけではありませんが、 のドキュメントには、クローン可能をディープ クローニングするかシャロー クローニングWonderfulBaseするかが示さWonderfulBaseれます。基本的に、ICloneableインターフェースは、 を定義することによって達成できないことは何も達成しませんICloneableWonderfulBase。
ICloneable物議を醸している BCL のアーティファクトの 1 つです。私見がそれを実装する本当の理由はありません。そうは言っても、クローン メソッドを作成する場合は を実装ICloneableし、独自の強力な型付きバージョンの を提供しCloneます。
問題は、非常に異なるものである浅いコピーか深いコピーかがICloneable示されないことです。Cloneないという事実は、ICloneable<T>ICloneable に関する Microsoft の考えを示している可能性があります。
マットは正しいです。使用しないでください。独自のCopy()メソッド (または類似の名前) を作成し、パブリック API で、メソッドがオブジェクトのディープ コピーまたはシャロー コピーを作成しているかどうかを完全に明確にします。