3 回答
TA贡献1788条经验 获得超4个赞
该ICloneable
接口本身并不是很有用,也就是说,实际上在很多情况下,知道一个对象是可克隆的而不知道其他任何信息都是有用的。这种情况与例如IEnumerable
or 截然不同IDisposable
。在许多情况下,接受一个有用的信息IEnumerable
而不是除枚举它以外的任何事情都是有用的。
另一方面,ICloneable
当与其他约束一起用作一般约束时,这可能会很有用。例如,基类可能有用地支持许多派生类,其中一些可以被有用地克隆,而另一些则不能。如果基本类型本身公开了公共克隆接口,则任何无法克隆的派生类型都将违反Liskov替换原理。避免此问题的方法是让基本类型支持使用Protected方法的克隆,并允许派生类型在合适的情况下实现公共克隆接口。
完成此操作后,可以将想要接受某种WonderfulBase
类型的对象并且需要能够克隆它的方法进行编码,以接受支持克隆的WonderfulBase对象(使用具有基本类型和ICloneable
约束的通用类型参数) 。尽管该ICloneable
接口本身并不表示深克隆或浅克隆,但有关文档WonderfulBase
将指出WonderfulBase
可克隆对象应是深克隆还是浅克隆。本质上,该ICloneable
接口不会完成定义所无法实现的任何事情ICloneableWonderfulBase
,只是该接口可以避免必须为每个不同的可克隆基类定义不同的名称。
TA贡献1802条经验 获得超5个赞
ICloneable
是BCL中存在争议的工件之一。恕我直言,没有真正的理由来实施它。这样说来,如果我要创建一个克隆方法,那么我会实现ICloneable
,并且提供我自己的强类型版本的Clone
。
问题ICloneable
是它从未表明Clone
是浅拷贝还是深拷贝,它们是完全不同的东西。没有任何事实ICloneable<T>
可能表明微软对ICloneable的想法
- 3 回答
- 0 关注
- 1387 浏览
添加回答
举报