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

对于那些在大型项目和API /框架设计方面具有丰富经验的人来说,这是一个问题.

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

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

让尽可能多的方法和属性保护虚拟是一个好主意吗？在什么情况下你会避免受保护的虚拟和使成员私有.

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

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

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

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

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

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