ICloneable VS 强类型函数 VS 惰性函数
大家好，我需要深度克隆一些引用其他自定义对象的自定义对象，这些对象可能引用其他自定义对象......等等，您明白了。
我只是在查看文档&目前处于构想阶段，所以不想把它做好。
Q1.当您可以编写返回正确克隆对象类型的强类型自定义函数时，为什么要实现 ICloneable 并返回对象呢？
Q2。这些对象并不大，我不介意进行最初的繁重工作来复制每个元素，但由于懒惰，我可以以成员方式克隆该对象，然后再次为引用的成员添加特定代码，这将需要进行强制转换，所以什么是更有效的就CPU周期而言？
任何想法、意见和建议欢迎思考。
Hi Folks I need to deep clone some custom objects that references other custom objects and these may reference other cust... and so on you get the idea.
I'm just at the documentation & conception stage at the moment so wan't to get it right.
Q1. Why implement ICloneable and return an object when you could write a strongly typed custom function that returns the correct object type cloned?
Q2. The objects are not huge and I don't mind doing the initial heavy lifting copying each element but being lazy I could memberwiseClone the object and then add specific code for the referenced members again this would create a need for casting, so what is more effiecient in terms of cpu cycles?
Any thoughts, opinions & musings welcomed.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
有关不实现 ICloneable 的原因，请参阅 536349；基本上，您可以定义自己的（强类型）接口并使用它，只要它正确记录它创建了深层副本，我就没有看到任何问题。
See 536349 for reasons not to implement ICloneable; basically you could define your own (strongly typed) interface and use that, I don't see any problems with it as long as it properly documents that it creates deep copies.
接口的目的是允许人们对支持该接口的对象进行操作，而不必担心该对象实际上是什么。如果不知道 iCloneable.Clone 实际上会对任何给定对象执行什么操作，仅仅知道对象支持 iCloneable 是毫无用处的。
对于集合类型来说，如果有一个受保护的 BaseClone 方法，并且有一个派生类型将其公开（这样做将允许人们从集合中派生可克隆和不可克隆类型），这将很有用。拥有像 Dictionary 这样的东西支持 Clone 方法会比包含复制构造函数更好，因为复制构造函数的参数可能是从 Dictionary 派生但内部显着不同的类型。
为了使克隆接口有用，它必须包含一个属性，通过该属性项目可以表达它们对克隆的感受（例如 -1- 类型是不可变的，不需要克隆；-2- 克隆类型可能会破坏它；-3-该类型支持克隆），并指定 DeepClone 操作将检查所有对象以确保它们不介意被克隆，如果是这种情况，它将克隆所有嵌套的可变对象。不幸的是，框架中不存在类似的东西。
The purpose of an interface is to allow people to operate upon objects that support the interface without having to worry about what the objects actually are. Without knowing what iCloneable.Clone is actually going to do on any given object, merely knowing that an object supports iCloneable is pretty useless.
It would have been useful for collection types to have a protected BaseClone method, and for them to have a derived type that would make it public (doing things that way would allow one to derive cloneable and non-cloneable types from the collections). Having something like Dictionary support a Clone method would be better than including a copy constructor, since the argument to a copy constructor could be a type which derived from Dictionary but was significantly different internally.
For a cloning interface to be useful, it would have to include a property by which items could say how they felt about cloning (e.g. -1- the type is immutable and doesn't need cloning; -2- cloning a type would likely break it; -3- the type supports cloning), and specify that a DeepClone operation would check all objects to make sure they didn't mind being cloning, and if that was the case, it would clone all nested mutable objects. Unfortunately, nothing like that exists in the framework.
如果一组派生类型包括可克隆和不可克隆版本，那么拥有一个指示对象可克隆的接口可能会很有用。如果某个类型的派生类可能不支持克隆，则该类型的克隆方法应该受到保护；该类型的可克隆版本应从该类型派生，但其他类型应从不可克隆版本派生。
例如，可以拥有一种类型 Widget，其派生类型包括 CloneableWidget 和 SuperWidget（不可克隆）。 SuperWidget 可以有一个派生类型 CloneableSuperWidget （以及其他一些在克隆时会破坏的类型）。如果希望能够使用 Widget 类型的所有可克隆派生类，则必须检查该对象是否派生自 Widget，并且它是可克隆的。将 iCloneable 添加到可克隆派生类中将允许检查此类对象。
Having an interface to indicate that an object is cloneable may be useful if a set of derived types includes cloneable and non-cloneable versions. If it's possible that derivatives of a type may not be able to support cloning, the cloning methods of that type should be Protected; a cloneable version of the type should be derived from it, but other types should derive from the non-cloneable versions.
For example, one could have a type Widget with derived types including CloneableWidget and SuperWidget (which isn't cloneable). SuperWidget could have a derived type CloneableSuperWidget (along with some others that would break if cloned). If one wants to be able to work with all cloneable derivatives of type Widget, one would have to check both that the object derives from Widget, and that it be cloneable. Adding iCloneable to the cloneable derivatives would allow one to check for such an object.