Why does WPF ship classes that have internal virtual methods?

Question

Today, I looked at the implementation of Thumb management to find out how it works. I was struck by the fact that there are 3 methods that seem to override the internal virtual parent methods, namely

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

I'm not so interested in what exactly these methods do, but rather they can be good reasons for redefining them only domestically (Microsoft). I could not find any obvious information about this.

Why it should be possible to extend some functions of Control / FrameworkElement / UIElement / etc. not accessible to the general user? It seems to me that the only plausible explanation is that this functionality is intended for certain WPF child classes, which is somehow a violation of OOP principles, isn't it?

I silently assume that not only Microsoft can say: "we can do something with our card, which you cannot, tee-hee."

Follow-up: Most of the internal material in Thumb was somehow related to visual states. Therefore, I came to the conclusion that I can safely get rid of this part of the interface in the new class that I create and implement my own visual states, if I ever need them.

Answer 1

I cannot speak with WPF specifically, but as someone who wrote (not officially supported) the libraries for Microsoft:

1) It does not violate the principles of OOP. DO NOT hide methods from external assemblies for which they have no reason - this will violate them. (Improper encapsulation)

2) This prevents the display of a heap of garbage that you do not need to use for the intellisense class. (which really is part number 1, but I’ll call him on purpose, because this is a big deal)

3) This simplifies testing.

I am sure there are other reasons that I do not think about.

In my particular case, I had a base class that wrapped the C Win32 API, and each derived class had to handle one of the three main uses of the API. For this, special methods had to be reevaluated. There is absolutely no reason for the end user of these classes to see this garbage.

I also want to note that in my particular case, I also found internal unacceptable, because I also wanted protected so that the class had to be internal for the AND assembly, derived from the base class, to access or override the method. protected internal allows either OR, and private protected not available at that time. I ended up finding an alternative approach that I can no longer recall. The point, I suspect, but not sure, is that internal is probably incorrect encapsulation in the sense that private protected would be preferable if it were available. (Although I understand that the CLR has always supported it. It's just not C # or VB.NET)

Last note: after reading your comments, I may have missed the real drift of your question. Experienced methods at Thumb probably process the material for the base class, and you should not impose direct output on you. Either because it will be too complicated, or because all possible derivatives are handled by derived classes. (For example, the base Shape class for the API for a mechanism that processes only rectangles and triangles. Given the Rectangle and Triangle , you have no reason to deduce from Shape. And at this point, there are probably Rectangle and Triangle stuff that processes the virtual methods that the you have no reason to know.) Another possible thing is methods that are processed in the base class, which can be obtained, but can be overridden for optimization purposes ... but only domestically because the open API surface area is simply not worth it.