设计建议-何时有效地使用“虚拟”和“密封”[关闭]

从开始 Microsoft Design Guidelines for Developing Class Libraries 尤其是 Extensibility 部分,您可以在其中找到文章 virtual members 和 sealing .

引用,这里:

• 不要使成员成为虚拟的,除非您有充分的理由这样做,并且您知道与设计、测试和维护虚拟成员相关的所有成本。

• 对于虚拟成员,确实更喜欢受保护的可访问性而不是公共可访问性。公共成员应该通过调用受保护的虚拟成员来提供可扩展性(如果需要)。

• 没有充分的理由不要密封类。

• 不要在密封类型上声明受保护或虚拟成员。
• 考虑密封您覆盖的成员。

不过,请阅读全文。

首先,我同意其他的答案,这些答案建议积极密封任何不是专门设计来扩展的内容。我不同意你需要一个密封的理由;相反,你需要一个不密封的理由。

你的问题很一般,所以这里有一个一般的答案:你的图书馆大概是 特征 可作为解决用户问题的工具。您的库中的每个特性大概都在那里,因为您做了一些研究,发现有一个用户问题需要解决,并为他们解决了它。

这些特性中的每一个都有与之相关的特定成本。其中一些成本是过去的——您花在设计、实现、测试、调试和交付代码上的时间。其中一些费用还没有到来:维护、阅读错误报告等等。还有一些更微妙的成本,比如,也许保持与现有功能之一的向后兼容性会增加明天实现新功能的成本。

可扩展性也是一个特性 . 这是一个功能,如果你弄错了,成本几乎完全在 未来 .像对待任何其他特性一样对待它:弄清楚它是否是您的用户真正需要的特性,以及它的好处是否支付了它的成本。如果您不能清楚地评估扩展性的好处或成本,那么不小心地实现它是非常危险的。

在我看来,你不能真正预见到你的用户最终会用它做什么。因此,一般来说,最好不要密封任何东西,除非有一些你不想让用户胡闹的内部行为(例如,他们需要知道,在你这样做之前必须先设置这一点,等等)。

至于虚拟,您倾向于使最终用户可能想要覆盖的任何虚拟内容。事件极大地减少了对虚拟功能的需求,但有时您仍然希望使它们成为虚拟的。一般来说,您需要考虑到任何给定的成员函数可能需要最终用户进行定制。

我说过很多次“该死的!为什么这个班是密封的!但是我从来没有说过“天哪-我希望他们能封住那门课!”

总有一天,一个比你更优秀的程序员很有可能想要扩展你的课程,并且知道他们在做什么。我认为很少有好的理由来封印。

声明方法 事实上的 暗示一个特定的契约:您的类接受它可以被重写并对此进行预期。

通常有一个明确的理由使某物虚拟化。有疑问时:不要。

和 密封的 恰恰相反,你可以声明你不想再被覆盖了。第二个原因可能是这里的性能,但我不会用得太快。

有争议的意见: C# classes should be sealed by default .

如果类不是被设计为要继承的,并且您没有考虑到潜在的缺陷或记录如何正确继承,那么如果人们重写方法,您的类很可能会以奇怪的方式失败。当你不密封你的类时,你告诉你的类的客户从它派生是可以的,并且你将来必须支持你的类的这个“接口”,以避免破坏那些选择从你的类继承的客户。这就限制了以后如何修改类。

所以默认情况下密封类,除非您明确希望允许这样做。如果您确实想允许它,请确保您通过创建虚拟的方法来记录哪些方法应该被重写,以及被重写的方法必须做些什么来确保类继续工作(例如调用基方法)。

通常,通过继承来设计类的可扩展性并不容易。当你密封一些东西时,你会说这个类确实不适合实现继承(例如,你可能在用不安全的代码做一些低级的事情)。

为了获得最大的可组合性(在数学意义上),我建议密封所有非抽象类的内容。实际上,这就是如何在语言(签出)中实现代数数据类型(在本例中是求和类型) http://blog.lab49.com/archives/3011 一篇惊心动魄的文章)。

你有兴趣 冲突 在这里。

• 如果您希望让呼叫者更容易测试他们的代码(例如进行测试驱动开发),那么您的用户需要能够 嘲弄 你的班级。
  • 因此,所有方法ECT必须是虚拟的,或者您必须具有包含所有方法的实现接口。
• 但是,如果您希望明确说明您在用户可能创建的任何子类上提供的合同,那么您应该遵守Microsoft指南。
  • 除非您有充分的理由这样做,并且您知道与设计、测试和维护虚拟成员相关的所有成本,否则不要使成员成为虚拟成员。 遗憾的是,没有一种方法可以标记一个虚拟方法来表示除了模拟之外,您不希望任何客户机代码实现它。