Geeks With Blogs
John Conwell: aka Turbo Research in the visual exploration of data

A few weeks ago I attended an AOP workshop at Microsoft.  One of the AOP flavors that was presented requires you to implement an interface for every class that you want to apply aspects too.  I find this fairly annoying and constricting.  When I voiced my concern about having to create one interface for every class in my 600 class architecture, I was told by the majority of the people there, from both academia and the CLR team, that this is how you should design your framework anyway.  That interfaces allows for the greatest extensibility.

Interestingly enough, I just started reading a book called Framework Design Guidelines, written by Krysztof Cwalina and Brad Abrams, both heavy hitters at Microsoft.  In chapter 4, Type Design Guidelines, they state that when designing a polymorphic hierarchy for reference types, in general, you should opt for using abstract classes vs interfaces.  The book states that when applying a “Is A“ relationship you should utilize an abstract class.  And if you are applying a “Can Do” relationship to a class, then you use an interface (IDisposable, IEnumerable, IComparable).  The main argument here is that interfaces should be immutable from version to version, but base classes can evolve with much greater ease.  The only major down side to using abstract classes vs interfaces is that .Net only allows 1 class inheritance, but you can interface inherit all day long. 

My main programming mantra states that there is no silver bullet.  There is no “One” tool.  Each tool has a purpose, and should only be used for that purpose and that purpose alone.  When designing a system, look at your requirements and use the tools that fit the situation appropriately.  Don't try to force the use of a tool just because you used it before.  Try to understand what the tool's use is for.  But it seems people are looking for the Matrix version of a programming tool.  The One...

When I here people saying “Every class should have an explicitly defined interface” it really makes me wonder where this comes from.  I have to think these guys are throwbacks from the COM days, who didn't really understand why COM did this.  They just understood that if it was a class, it had an interface, and they didn't need to know why. 

Now, the really interesting thing is that both the authors for the Framework Design Guidelines book are program managers for the CLR team, yet there were people in their team spouting the interface mantra.

Posted on Tuesday, November 29, 2005 6:10 AM | Back to top

Comments on this post: Interfaces or abstract classes, or There is no silver bullet

No comments posted yet.
Your comment:
 (will show your gravatar)

Copyright © John Conwell | Powered by: