今天我看一下Thumb控件的实现，以了解它是如何工作的。让我印象深刻的是，有3种方法似乎覆盖了内部虚拟父方法，即
internal override int EffectiveValuesInitialSize {get;}
internal override DependencyObjectType DTypeThemeStyleKey {get;}
internal override void ChangeVisualState(bool useTransitions);
我对这些方法具体做什么并不感兴趣，而是允许仅在内部覆盖它们的有效理由（Microsoft）。我无法找到任何关于此的明显信息。
为什么能够扩展Control / FrameworkElement / UIElement / etc的某些功能。普通用户无法使用？对我来说唯一合理的解释似乎是，这个功能是针对WPF的特定子类设计的，这在某种程度上违反了OOP原则，不是吗？
我默默地认为，不仅仅是微软可以说：＆＃34;我们可以用我们的框架来做一些你不能做到的事情，但是，＃tee;＆＃34;。
跟进： Thumb中的大多数内部资料都与视觉状态有关。所以我得出的结论是，我可以安全地摆脱我正在创建的新类中的接口部分，并在需要时实现我自己的视觉状态。
答案 0 :(得分：5)
我无法专门与WPF对话，但作为为Microsoft编写（非官方支持）库的人：
1）它没有违反OOP原则。不要从他们没有理由知道的外部程序集中隐藏方法会违反它们。 （封装不当）
2）它可以防止intellisense显示你不需要使用该类的一堆垃圾。 （这真的是＃1的一部分，但我会特别说出来，因为这是一个大问题）
3）它使更多的测试更容易。
我确定还有其他原因，我没想到。
在我的特定情况下，我有一个包装C Win32 API的基类，每个派生类必须处理API的三个主要用途之一。必须覆盖特定的方法来做到这一点。绝对没有理由让这些类的最终用户看到那个垃圾。
另外我还要注意，在我的特定情况下，我也发现internal令人反感，因为我也想要protected，因此一个类必须是程序集的内部并且从基数派生出来用于访问或覆盖方法的类。 protected internal允许使用OR，并且private protected当时不可用。我最终找到了一些我不能再回忆的替代方法。重点是，我怀疑 - 但不确定 - internal可能是不恰当的封装，因为private protected在可用的情况下是首选。 （虽然我理解CLR一直支持它。只是不支持C＃或VB.NET）
最后注意：阅读您的评论，我可能错过了您的问题的真正偏差。 Thumb中的重写方法可能正在处理基类的内容，而您无意直接派生它们。要么是因为这样做会使FAR过于复杂，要么因为每个可能的派生都是由派生类处理的。 （例如，对于仅处理矩形和三角形的引擎的API的Shape基类。提供Rectangle和Triangle，您没有理由从Shape派生。并且在那时有可能是Rectangle和Triangle通过你无法理解的虚拟方法处理的东西。）另一个可能的东西是在基类中处理得很好的方法，可以从中派生，但可以为优化目的而重写...但仅在内部，因为暴露的API表面区域不值得。