こんにちは皆さん 他のカスタム オブジェクトを参照するいくつかのカスタム オブジェクトをディープ クローンする必要がありますが、これらは他のカスタム オブジェクトを参照する可能性があります。
現時点では、ドキュメンテーションと構想の段階にあるだけなので、正しく理解するつもりはありません。
Q1. クローンされた正しいオブジェクト型を返す厳密に型指定されたカスタム関数を記述できるのに、なぜ ICloneable を実装してオブジェクトを返すのでしょうか?
Q2. オブジェクトは巨大ではなく、各要素をコピーする最初の面倒な作業を行うことは気にしませんが、オブジェクトをメンバーごとに複製し、参照されたメンバーの特定のコードを再度追加すると、キャストが必要になるため、より効率的です。 CPUサイクルの観点から？
どんな考え、意見、熟考も歓迎します。
ICloneableを実装しない理由については、 536349を参照してください。基本的に、独自の (厳密に型指定された) インターフェイスを定義してそれを使用することができます。ディープ コピーを作成することが適切に文書化されている限り、問題はありません。
インターフェイスの目的は、オブジェクトが実際に何であるかを気にすることなく、インターフェイスをサポートするオブジェクトを操作できるようにすることです。特定のオブジェクトに対して iCloneable.Clone が実際に何をするかを知らずに、オブジェクトが iCloneable をサポートしていることを知っているだけでは、まったく役に立ちません。
コレクション型に保護された BaseClone メソッドがあり、それをパブリックにする派生型があると便利でした (そのようにすることで、コレクションから複製可能な型と複製できない型を派生させることができます)。コピー コンストラクターへの引数は、Dictionary から派生した型である可能性がありますが、内部的には大幅に異なるため、Dictionary サポートのようなものを Clone メソッドに含める方が良いでしょう。
クローニング インターフェースが有用であるためには、項目がクローニングについてどのように感じたかを示すことができるプロパティを含める必要があります (例: -1- 型は不変であり、クローニングは必要ありません; -2- 型のクローニングは壊れる可能性があります)。 -3- タイプはクローン作成をサポートします)、DeepClone 操作がすべてのオブジェクトをチェックしてクローン作成を気にしないことを確認し、その場合はネストされたすべての変更可能なオブジェクトをクローンするように指定します。残念ながら、フレームワークにはそのようなものはありません。
オブジェクトが複製可能であることを示すインターフェースを持つことは、一連の派生型に複製可能なバージョンと複製不可能なバージョンが含まれている場合に役立ちます。型の派生物が複製をサポートできない可能性がある場合は、その型の複製メソッドを Protected にする必要があります。型の複製可能なバージョンはそれから派生する必要がありますが、他の型は複製不可能なバージョンから派生する必要があります。
たとえば、CloneableWidget や SuperWidget (複製可能ではない) などの派生型を持つ Widget 型を持つことができます。SuperWidget は、派生型 CloneableSuperWidget を持つことができます (複製すると壊れる他のいくつかのものと一緒に)。Widget 型の複製可能なすべての派生物を操作できるようにしたい場合は、オブジェクトが Widget から派生していることと、複製可能であることの両方を確認する必要があります。クローン可能な派生物に iCloneable を追加すると、そのようなオブジェクトをチェックできるようになります。