嗨，伙计们，我需要深度克隆一些引用其他自定义对象的自定义对象，这些对象可能会引用其他自定义对象……等等，你明白了。
我现在只是在文档和概念阶段，所以不想把它弄好。
Q1。当您可以编写一个返回正确的克隆对象类型的强类型自定义函数时，为什么要实现 ICloneable 并返回一个对象？
Q2。对象并不大，我不介意复制每个元素进行最初的繁重工作，但是因为懒惰我可以 memberwiseClone 对象，然后再次为引用的成员添加特定代码，这将需要强制转换，所以更高效在 CPU 周期方面？
欢迎任何想法，意见和沉思。
有关不实施 ICloneable 的原因，请参阅536349 ；基本上，您可以定义自己的（强类型）接口并使用它，只要它正确记录了它创建的深层副本，我认为它没有任何问题。
接口的目的是允许人们对支持接口的对象进行操作，而不必担心对象实际上是什么。如果不知道 iCloneable.Clone 实际上会对任何给定对象做什么，仅仅知道一个对象支持 iCloneable 是毫无用处的。
如果集合类型有一个受保护的 BaseClone 方法，并且它们有一个派生类型将其公开（这样做将允许人们从集合中派生可克隆和不可克隆类型），这将很有用。让 Dictionary 之类的东西支持 Clone 方法比包含复制构造函数要好，因为复制构造函数的参数可能是从 Dictionary 派生但内部显着不同的类型。
为了使克隆接口有用，它必须包含一个属性，通过该属性项目可以说出它们对克隆的感受（例如 -1- 类型是不可变的并且不需要克隆；-2- 克隆类型可能会破坏它；-3- 类型支持克隆），并指定 DeepClone 操作将检查所有对象以确保它们不介意被克隆，如果是这种情况，它将克隆所有嵌套的可变对象。不幸的是，框架中不存在类似的东西。
如果一组派生类型包括可克隆和不可克隆版本，则具有指示对象可克隆的接口可能很有用。如果某个类型的派生可能无法支持克隆，则该类型的克隆方法应该是受保护的；该类型的可克隆版本应该从它派生，但其他类型应该从不可克隆版本派生。
例如，可以有一个 Widget 类型，其派生类型包括 CloneableWidget 和 SuperWidget（不可克隆）。SuperWidget 可以有一个派生类型 CloneableSuperWidget（以及其他一些在克隆时会中断的类型）。如果希望能够使用 Widget 类型的所有可克隆派生类，则必须检查该对象是否派生自 Widget 以及它是否可克隆。将 iCloneable 添加到可克隆派生类将允许人们检查这样的对象。