Mar 22, 2013 at 6:00 AM
Edited Mar 22, 2013 at 6:02 AM
Yeah, but the point is that there will not be any significant changes to that class because the code of significance is somewhere else. If there was significant code in that class than it would be different and it should in fact be protected. As such,
the fact that is isn't gives you a specific indication that this class was not designed to hold significant code.
I understand completely where you came from. In the VFP world, inheritance was a) extremely powerful, and b) the only such tool we had. In the .NET world, we have inheritance with even greater power, but we also have additional features that allow us to define
exactly how inheritance works. We also have other tools such as interfaces (and interface inheritance), delegates, and more, which are also very valuable tools that are often more appropriate than plain old implementation inheritance. But like I said: I understand
where you are coming from, because when I originally moved into .NET, I also tried to deploy the inheritance hammer everywhere.
Also, changing attributes/methods/etc. to be protected (and virtual) does not expose those values any more than as protected except to subclasses.
OK, there are a few confusing things here. I assume when you say "attribute" you mean "property", because attributes do not participate in this mechanism as such.
I also assume you mean "protected exposes things no more than private
". In that case: Yes, protected does in fact expose things more. In .NET, inheritance works in a way where the two classes that participate in an inheritance relationship
form two object instances in memory. The first one then exposes everything that is protected or public to the other one. Not the private ones though. So there is a great difference there. Now for something like a property, the idea is that ANYTHING outside
that class always accesses the property's values through the set/get method pair. You NEVER would want to access the backing field from a subclass.
It is also very important to understand that just because something isn't virtual, that doesn't mean you can't inherit from it and override it. So this is perfectly valid:
public class Dog
public string Bark()
public class BigDog : Dog
public new string Bark()
So this works perfectly fine even though the method in the superclass is not flagged as virtual. So there is no need to copy and paste if you want to do this sort of stuff with the framework classes. (Note: I think we have a paper on VFPConversion.com that
explains the finer points of all this stuff, with a VFP slant)
Also, as mentioned in my prior post: Virtual methods introduce significant runtime overhead. So it is NOT desirable to make all methods virtual, especially on framework level.
And, to add a general statement again: There really shouldn't be that much or a reason for you to have to subclass much from the framework. I know that in VFP that was the recommendation, but in hindsight, that recommendation only really made sense for the
UI classes (which does not at all apply in WPF). So the need to subclass everything simply doesn't exist in .NET.