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 で、メソッドがオブジェクトのディープ コピーまたはシャロー コピーを作成しているかどうかを完全に明確にします。