Why do WPF shipped classes have internal virtual methods?

Question

Today I have taken a look at the implementation of the Thumb control in order to learn how it works. What struck me is, that there are 3 methods which seem to override internal virtual parent methods, namely

internal override int EffectiveValuesInitialSize {get;}
internal override DependencyObjectType DTypeThemeStyleKey {get;}
internal override void ChangeVisualState(bool useTransitions);

I am not so much interested in what these methods do specifically, but rather what could be valid reasons to allow overriding them only internally (Microsoft). I couldn't find any obvious information about this.

Why should the ability to extend some functionality of Control/FrameworkElement/UIElement/etc. not be available to the general user? To me the only plausible explanation seems to be, that this functionality is designed for specific child classes of WPF, which is somehow a violation of OOP principles, isn't it?

I silently assume that it's not just that Microsoft can say: "we can do something with our framework that you can't, tee-hee".

Follow-up: most of the internal stuff in Thumb was somehow related to visual states. So I have come to the conclusion that I can safely get rid of that part of the interface in the new class I am creating, and implement my own visual states if I ever need them.

Answer 1

I can't speak to WPF specifically, but as someone who has written (not officially supported) libraries for Microsoft:

1) It doesn't violate OOP principles. NOT hiding methods from external assemblies they have no reason to know about would violate them. (Improper encapsulation)

2) It prevents intellisense from showing a bunch of junk that you don't need to use the class. (which is really part of #1, but I'll call it out specifically, because it's a big deal)

3) It makes testing much easier.

I'm sure there are other reasons for it I'm not thinking of.

In my particular case I had a base class wrapping a C Win32 API, and each derived class had to handle one of three major uses of the API. Particular methods had to be overriden to do that. Absolutely no reason for an end user of these classes to see that junk.

Also I'll note that in my particular case I also found internal objectionable because I also wanted protected so that a class would have to be internal to the assembly AND derived from the base class to access or override the method. protected internal allows either OR, and private protected was not available at the time. I ended up finding some alternate approach I can no longer recall. Point being, I suspect--but am not sure--internal is probably improper encapsulation in the sense that private protected would have been preferred had it been available. (Although I understand the CLR has always supported it. Just not C# or VB.NET)

Last note: Reading your comments, I may have missed the real drift of your question. The overriden methods in Thumb are probably handling stuff for a base class that there is no intention for you to derive from directly. Either because doing so would be FAR too complicated, or because every possible derivation is handled by the derived classes. (Such as a Shape base class for an API for an engine that only handles rectangles and triangles. Provided Rectangle and Triangle, you have no reason to derive from Shape. And at that point, there's probably stuff that Rectangle and Triangle handle through virtual methods that you have no possible reason to know about.) The other possible thing is methods that are handled fine in the base class which can be derived from, but can be overridden for optimization purposes...but only internally because the exposed API surface area just isn't worth it.