I´ve tried to use the ToolTip Property of the DropDownList ASP .NET control in ASP .NET. I´ve used the base class WebControl (Polymorphism). Because the base class has the property I thought that I can set the ToolTip. But I´ve seen that the property is hided in the derived class with funky attributes like [Bindable, DesignerSerializationVisibility, EditorBrowsable, Browsable] to hide them in Visual Studio Intellisense, ... But I can compile the code, because the Property is implemented in the DropDownList class (must be because od OO). The get_ method returns an String.Empty and the set_ method does nothing.
I think thats a violation of the "Liskov Substitution Principle": "A subclass will always work where its base classes are used."
Is it a violation and if it is, when does M$ provide the developers a GOOD designed framework ?
Another example for a bad design is in the XslTransform class. Some of the overloaded methods to transform will ignore the disable-output-escaping xsl attribute. ONE overloaded method will succeed, but only if I transform it into a stream !? I´ve found the documentation of that "design failure" here:
What´s about that ?! How can the USER/DEVELOPER know that the SAME method has different results ?
I hope that the developers will receive a better framework to work more efficient.
The Liskov Substitution Principle is broken in many places in the framework.
This is a problem that generics might help to solve?
I dont´t think that the generics solve this problem. See the C++ templates - and there is a lot of C++ Code that broke the LSP. No technology (for now) forces you to have a good design.
I think the .NET Framework is very good. But I think there can be some improvements to make it 99,99% efficient for the developers.
I don´t want to goose - I want to give some hints of parts that could be improved - in my point of view. I want a "perfect" .NET Framework - I know that a "perfect software" is impossible !
This is good feedback. You will see improvements in the Whidbey time frame with respect to enhanced core design in the BCL. This trend will continue with the BCL in the Longhorn time frame.
I'd imagine it's not entirely unreasonable to expect a very large and complex class library like FX to fully comply with LSP. On the other hand, it's probably unreasonable to expect a perfectly designed framework at the 1.1 stage. It's getting better in Whidbey, but as always there will still be room for improvement going forward. Stay tuned.
Keep on posting,