Ed: This is a repost of a rant that went down with the ship when my ill-fated alternate blog disappeared from my grasp…there are a few other posts from the old blog that I will be bringing over thanks to the magic of Windows Live Writer.
I’ve only mentioned this idea to a few people in the past. But things have gotten to the point where I’ve just got to put my thoughts out there. (This is me in my Champion role).
Back in college, one of the Comp Sci. professors hailed Java as a solution to all of the problems with C++. The problem with C++ as he saw it was that memory management was full of pitfalls. Even as a first year CS student, I felt that there was a simple solution to this problem: learn about and avoid those pitfalls. I felt that Java was restricting my creativity by telling me that I don’t want to deal with pointers and memory management. In all honesty, I don’t miss memory management, but I felt that someone was treating me like a kid and spelling out what they didn’t want me to hear. The big argument against garbage collection and the JVM was the performance hit that came with the two. Moore’s law took away the teeth of that argument. Of course I never lost my personal distaste for being coddled.
Recently, I read about a decision by Microsoft not to provide an IHttpContext interface but instead to provide an HttpContextBase abstract class. The reasoning: changing the interface would break implementations. I remember when the solution to this problem was to extend the interface when changes needed to be made. Existing implementations would not be broken and clients would check for the interface that they needed.
The big drawback to using an abstract base class instead of an interface is that you are using your sole parent class. (Another instance of hand-holding…Multiple Inheritance can cause problems if used incorrectly thus it’s bad and should be disallowed, why do I feel like I’m living in the world of Huxley’s Brave New World.) Besides, the primary benefit of the IHttpContext is that it can be mocked out, most Mock Frameworks work on interfaces not abstract classes. Because there’s a potential for the interface to be changed (again what’s wrong with using extension) let’s protect implementers from that change — and cripple the framework — by using an abstract base class instead.
This brings me to case 3: Silverlight’s control templating. Compared to the control template model in WPF, Silverlight’s model is definitely dumbed down…even to the extent of breaking the much ballyhooed designer-developer workflow. The argument for Silverlight’s model is that it makes it easier for tool designers to automatically discover hooks for reacting to predefined triggers. To me it takes the powerful expressive abilities of WPF’s control model and limits the design of a control to changes that the developer had the foresight to define. Or even worse! It requires a control to be extended or a new control to be created in order to enable a change the look and feel that hadn’t been pre-coded. WTF? I thought we were getting away from this with WPF.
To me the only person who benefits from this crippled design is a tool vendor. It makes their task much easier: just iterate over control parts and inform the designer what events they can respond to. Let’s say the Button didn’t provide a control part for the mouse down event (yes I know a very contrived example but it’s easy to see the impact of this lack of foresight). In WPF it’s not a problem, the designer creates an event trigger for the event in XAML and uses setters to change the look according to their design. In Silverlight…well, you are SOL, you have to extend or re-implement the button and code it with that control part to enable a different look and feel for the mouse down event.
My point here…I wish tool vendors would stop holding our hands. If you must provide an abstraction for an easier entry point, do so. But don’t do it to the exclusion of providing a more powerful alternative for those who have a grasp on the basics and want to go beyond.