ICloneableをC＃で実装する必要があるのはなぜですか？

メソッドを継承しICloneableて実装する理由を教えていただけますClone()か？

ディープコピーを実行する場合、メソッドを実装することはできませんか？言いましょうMyClone()か？

なぜ継承する必要がありICloneableますか？利点は何ですか？コードを「読みやすく」するだけの問題ですか？

すべきではない。メソッドが "ディープ"または "シャロー"のどちらのクローンを実行するICloneableかがインターフェイスから明確に示されていないため、マイクロソフトでは実装しないことをお勧めしますClone。

詳細については、2003年のBrad Abramsによるこのブログ投稿（！）を参照してください。

ICloneableインタフェースそれ自体では、実際にそれがオブジェクトはそれについて何も知らずに複製可能であることを知っておくと便利です多くの状況が存在していないと言うことである、非常に有用ではありません。これは、eg IEnumerableやとは非常に異なる状況IDisposableです。それIEnumerableを列挙する方法以外の何も知らずにを受け入れることが役立つ多くの状況があります。

一方、他のICloneable制約と一緒に一般的な制約として適用すると便利です。たとえば、基本クラスは、いくつかの派生物を効果的にサポートする場合があり、その一部は効果的に複製でき、一部はできません。ベースタイプ自体がパブリッククローンインターフェイスを公開している場合、クローンを作成できなかった派生タイプは、リスコフの置換原則に違反します。この問題を回避する方法は、基本型にProtectedメソッドを使用した複製をサポートさせ、派生型がパブリッククローンインターフェイスを適切に実装できるようにすることです。

それが完了すると、WonderfulBase型のオブジェクトを受け入れ、それを複製できるようにする必要があるメソッドをコーディングして、複製をサポートするWonderfulBaseオブジェクトを受け入れるようにコーディングできます（基本型とICloneable制約のあるジェネリック型パラメーターを使用） 。がICloneableインタフェース自体が深い又は浅いクローンを示さないであろう、のドキュメントは、WonderfulBase複製可能かどうかを示すことになるWonderfulBaseディープまたは浅いクローニングしなければなりません。基本的に、ICloneableインターフェイスはICloneableWonderfulBase、を定義しても達成できないことは何も達成しませんが、クローン可能な基本クラスごとに異なる名前を定義する必要がありません。

ICloneable物議を醸しているBCLのアーティファクトの1つです。IMHOを実装する本当の理由はありません。それで、クローンメソッドを作成する場合は、実装を行いICloneable、独自の強力な型指定バージョンを提供しますClone。

の問題は、非常に異なるものである浅いコピーと深いコピーのどちらであるICloneableかCloneが示されることはありません。ないという事実は、ICloneable<T>ICloneableに関するマイクロソフトの考えを示している可能性があります。

マットは正解です。使用しないでください。独自のCopy()メソッド（または同様の名前）を作成し、メソッドがオブジェクトの深いコピーと浅いコピーのどちらを作成しているかを、パブリックAPI で完全に明確にします。