Design Corruption

time to read 2 min | 325 words

A short time ago, I commented on the problematic decision to move from interfaces to base classes in the MS MVC framework. Hammett has left the following comment there:

Now its abstract class, then they will protected internal by default, and in the end people will get the usual MS tool, while this could be a break from the old habits.

Phil Haack, today (emphasis mine):

This is why there tends to be an emphasis on Abstract Base Classes as I mentioned before within the .NET Framework. Fortunately, when the ABC keeps most, if not all, methods abstract or virtual, then testability is not affected.

I think that this sums it up pretty well. And this is a major concern to me. Once you make design concessions, you end up with a corrupted design. And yes, I do think that the traditional, Framework Design Guidelines driven, design methods are broken. They lead to a design that is very hard to work with in many cases.

My objections remains the same, abstract base classes limits my options and make my life harder. I understand the difference between writing a framework and writing an application, make no mistake. But I think that the burden is on the framework developer.

There is a very simple, widely accepted, solution for this issue, have an interface in place, supply a base class for the people who want that, and move on with your life. The guarantee that you make is that if you use the base class, you wouldn't have breaking changes. If you are using the interface directly, that is your responsibility.

You know what, it works, very well.

Beside the point, if someone will give me a hook to the assembly loading stuff, I will patch the code on the fly to add the missing members.