您是否曾经拥有太多“受保护的虚拟”网络？ 方法？
对于那些具有大型项目和 API/框架设计经验的人来说，这是一个问题。
我正在开发一个框架，将来会被许多其他项目使用，所以我想让它变得漂亮且可扩展，但同时它需要简单且易于理解。
我知道很多人抱怨 .NET 框架包含太多密封类和私有成员。 我应该避免这种批评并开放我的所有课程并提供大量受保护的虚拟成员吗？
让尽可能多的方法和属性受保护的虚拟是一个好主意吗？ 在什么情况下您会避免受保护的虚拟并将成员设置为私有。
Here's a question for those of you with experience in larger projects and API/framework design.
I am working on a framework that will be used by many other projects in the future, so I want to make it nice and extensible, but at the same time it needs to be simple and easy to understand.
I know that a lot of people complain that the .NET framework contains too many sealed classes and private members. Should I avoid this criticism and open up all my classes with plenty of protected virtual members?
Is it a good idea to make as many of my methods and properties protected virtual as possible? Under what situations would you avoid protected virtual and make members private.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
我的观点是：
事件，那么它优先于受保护的方法。My point of view is:
events, its preferred toprotectedmethods.protectedmethods as possible, if not possible then you have to use it ;-).选择
protected而不是private是经过深思熟虑的设计决策。 您声明您的类明确支持使用该函数，以及随之而来的所有开销（设计和实现工作）。 我只会在我知道有必要的情况下使用protected，主要是因为我自己这样做。 （您还会发现 BCL 开发人员的评论与我所说的一致。）虚拟/非虚拟性能差异在任何机器上都无关紧要。足够强大来运行.NET Framework。Choosing
protectedoverprivateis a deliberate design decision. You are stating that your class explicitly supports having that function used, with all the overhead (design and implementation effort) that comes with that. I would only useprotectedin those situations where I know that it is necessary, largely because I am doing it myself. (You'll also find comments from BCL developers along the same lines as what I have said.)The
virtual/non-virtualperformance difference is irrelevant on any machine that is powerful enough to run the .NET Framework.不，你不能拥有“太多”。 然而，我们应该让所有内容都受到保护而不是私有或不惜一切代价避免“密封”的想法是愚蠢的。 我会将“辅助方法”和内部数据结构保密。
No, you can't have "too many." However, the idea that we should just make every protected instead of private or avoid "sealed" at all costs is just silly. I would keep "helper methods" and internal data structures private.
不太好主意。
受保护的虚拟方法在增加耦合的同时在框架中提供了可扩展点。
有更有前景的技术可以提供可扩展性：组合 和 委托。
Not as good idea.
Protected virtual methods provide extensibility points in the framework while adding coupling.
There are more promising techniques to provide extensibility: Composition and Delegation.
当您用“virtual”一词标记一个方法时，您就允许用户更改该逻辑的执行方式。 对于许多目的来说，这正是您想要的。 我相信你已经知道了。
然而，类型应该针对这种扩展而设计。 您必须主动选择让用户改变行为有意义的方法。 如果您只是在各处使用虚拟，则可能会破坏类型的完整性，这并不能真正帮助用户理解类型，并且可能会引入许多错误，包括与安全相关的问题。
我更喜欢保守的方法。 我用
sealed标记所有类，除非我特别想启用继承，并且在这些（少数）情况下，我只将所需的方法设为虚拟。如果将来需要更改类以允许继承，则可以轻松删除
sealed标记。 但是，如果您想要更改已用作某些其他类型的基类的类，则在更改基类时可能会破坏子类。When you mark a method with the word virtual, you're allowing the users to change the way that piece of logic is executed. For many purposes, that is exactly what you want. I believe you already know that.
However, types should be designed for this sort of extension. You have to actively pick out the methods, where it makes sense to let the user change the behavior. If you just slap on virtual all over the place you risk ruining the integrity of the type, it doesn't really help the user to understand the type, and you may introduce a number of bugs including security related issues.
I prefer the conservative approach. I mark all my classes with
sealedunless I specifically want to enable inheritance and in those (few) cases I only make the required methods virtual.It is easy to remove the
sealedtag if the class needs to change to allow inheritance in the future. However, if you want to change a class, which is already being used as a base class for some other type, you risk breaking the subclass when you change the base class.你的类包含数据成员； 对那些功能永远不应该改变的数据成员执行基本内部操作的方法应该始终是私有的。 因此，对数据成员执行基本操作（例如初始化和分配）的方法应该是私有的。 否则，您将面临“二阶”派生类启用不完整行为集的风险； 一阶导数成员可能会重新定义类的行为。
总而言之，我认为您应该非常小心地将方法定义为“受保护的虚拟”。 我在将方法定义为“受保护的虚拟”时会非常谨慎，因为这样做不仅声明了重写功能的可能性，而且在某些方面定义了重写的期望功能。 在我看来，这听起来像是一组未定义的需要覆盖的行为； 我宁愿有一组明确定义的行为来覆盖。 如果您想要拥有大量可重写的行为，我宁愿研究面向方面的编程，它以非常结构化的方式允许此类事情。
Your class includes data members; methods that perform basic internal operations on those data members where the functionality should never change should always be private. So methods that do basic operations with your data members such as initialization and allocation should be private. Otherwise, you run the risk of "second order" derivative classes getting an incomplete set of behaviors enabled; first derivative members could potentially redefine the behavior of the class.
That all said, I think you should be very careful with defining methods as "protected virtual". I would use great caution in defining methods as "protected virtual", because doing so not only declares the possibility of overriding the functionality, but in some ways define an expectation of overridden functionality. That sounds to me like an underdefined set of behaviors to override; I would rather have a well-defined set of behaviors to override. If you want to have a very large set of overridable behaviors, I would rather look into Aspect Oriented Programming, which allows for that sort of thing in a very structured way.