為什么WPF附帶的類具有內部虛擬方法？

Question

今天，我研究了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原理，不是嗎？

我默默地認為，不僅僅是微軟可以說：“我們可以使用您的框架做一些您不能做到的事情，”

后續行動： Thumb的大部分內部內容都與視覺狀態有關。 因此，我得出的結論是，我可以放心地擺脫正在創建的新類中的接口部分，並在需要時實現自己的視覺狀態。

Answer 1

我不能專門與WPF交流，但是作為為Microsoft編寫（不受官方支持）庫的人：

1）它不違反OOP原則。 不要從沒有理由知道的外部程序集中隱藏方法會違反它們。 （封裝不當）

2）它可以防止智能感知顯示一堆不需要使用該類的垃圾。 （這確實是＃1的一部分，但是我會特別指出，因為這很重要）

3）它使測試容易得多 。

我敢肯定還有其他我沒有想到的原因。

在我的特殊情況下，我有一個包裝C Win32 API的基類，每個派生類必須處理API的三種主要用途之一。 為此，必須重寫特定的方法。 這些類的最終用戶絕對沒有理由看到該垃圾。

我還要指出，在我的特殊情況下，我也發現internal因為我也想protected這樣一來，一個類就必須在程序集內部並從基類派生，才能訪問或覆蓋該方法。 protected internal允許“或”，而那時private protected不可用。 最后，我找到了一些我不再想起的替代方法。 從本質上講，我懷疑-但不確定- internal封裝可能不正確，從某種意義上說，如果有internal private protected話，內部private protected將是首選。 （盡管我知道CLR一直都支持它。只是不支持C＃或VB.NET）

最后說明：閱讀您的評論，我可能錯過了您提出的問題的真正含義。 Thumb中的重寫方法可能正在處理基類的內容，這些基類無意直接從中派生。 要么因為這樣做會使FAR太復雜，要么因為每個可能的派生都由派生類處理。 （例如，僅用於處理矩形和三角形的引擎的API的Shape基類。如果提供Rectangle和Triangle ，則沒有理由從Shape派生。到那時，可能Rectangle和Triangle可以通過虛擬方法進行處理您可能沒有理由不知道。）另一種可能是在基類中可以很好地處理的方法，這些方法可以派生自但可以出於優化目的而覆蓋...但僅限於內部使用，因為暴露的API表面積只是不值得。