你有没有太多“受保护的虚拟”方法？

Question

对于那些具有大型项目和API /框架设计经验的人来说，这是一个问题。

我正在开发一个将来会被许多其他项目使用的框架，所以我想让它变得更好和可扩展，但同时它需要简单易懂。

我知道很多人抱怨.NET框架包含太多密封类和私有成员。我是否应该避免这种批评并用大量受保护的虚拟成员打开我的所有课程？

尽可能多地制作我的方法和属性受保护的虚拟是一个好主意吗？在什么情况下你会避免受保护的虚拟并使成员保密。

Answer 1

您的课程包括数据成员;对那些功能永远不会改变的数据成员执行基本内部操作的方法应该始终是私有的。因此，对数据成员执行基本操作的方法（如初始化和分配）应该是私有的。否则，您将面临“二阶”派生类获得一组不完整行为的风险;一阶衍生成员可能会重新定义该阶级的行为。

所有人都说，我认为你应该非常小心地将方法定义为“受保护的虚拟”。在将方法定义为“受保护的虚拟”时我会非常谨慎，因为这样做不仅声明了覆盖功能的可能性，而且在某些方面定义了被覆盖的期望功能。这听起来像是一个未定义的行为要覆盖;我宁愿有一套定义明确的行为来覆盖。如果你想拥有一大堆可覆盖的行为，我宁愿研究面向方面的编程，它允许以一种非常有条理的方式进行这种事情。

Answer 2

当您使用单词virtual标记方法时，您允许用户更改执行该逻辑的方式。出于许多目的，这正是您想要的。我相信你已经知道了。

但是，应为此类扩展设计类型。您必须主动选择方法，让用户改变行为是有意义的。如果您只是在整个虚拟区域上进行虚拟操作，则可能会破坏该类型的完整性，但这并不能帮助用户理解该类型，并且您可能会引入一些错误，包括与安全相关的问题。

我更喜欢保守的做法。我用sealed标记我的所有类，除非我特别想要启用继承，在那些（少数）情况下我只将所需的方法设为虚拟。

如果类需要更改为允许将来继承，则很容易删除sealed标记。但是，如果要更改已用作某些其他类型的基类的类，则在更改基类时可能会破坏子类。

Answer 3

我的观点是：

• 如果您可以使用events，则首选protected方法。
• 尽量避免使用protected方法，如果不可能，则必须使用它; - ）。

Answer 4

选择protected而非private是一项深思熟虑的设计决策。您声明您的类明确支持使用该函数，并带有所有开销（设计和实现工作）。我只会在我知道有必要的情况下使用protected，主要是因为我自己这样做。 （您也会发现BCL开发人员的评论与我所说的相同。）

virtual /非 - virtual性能差异与任何功能足以运行.NET Framework的计算机无关。

Answer 5

不，你不能“太多”。然而，我们应该让所有受保护而不是私人或不惜一切代价避免“密封”的想法是愚蠢的。我会保持“帮助方法”和内部数据结构私有。

Answer 6

  

尽可能多地制作我的方法和属性protected virtual是不是一个好主意？

不太好主意。

受保护的虚拟方法在添加耦合时在框架中提供可扩展性点。

有更多有前途的技术可以提供可扩展性：Composition和Delegation。