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