Interfaces vs Abstract [Base] Classes Reloaded

News

Navigation

Blogs I Read

Share this post: email it! | bookmark it! | digg it! | reddit! | kick it! | live it!

Posted: Jul 07 2006, 06:56 PM by scott | with 416 comment(s)
Filed under: OOAD

Comments

dr_williamson said:

Well, Scott, it seems you are learning something! :) I do remember your original article, and I must confess that at the time I just rolled my eyes and continued about my business.

I’m glad to see that you’ve corrected one of the mistakes you made in your first article (which was unfortunately a premise upon which some of the remainder of your article was built) which was stating that “inheritance [using Abstract Base Classes...] means ‘is a’, whereas using an Interface means ‘behaves as ‘.”

Yes, inheritance does mean “is a”, but when you implement a class that derives from a pure abstract base class, you are in effect implementing the interface defined by your abstract base class, thereby implementing behaviour (i.e. “behaves as a”) rather than creating a DerivedClass that “is an” AbstractBaseClass. If you then derive from DerivedClass, then sure, DerivedDerivedClass “is a” DerivedClass, but DerivedClass “behaves like an” AbstractBaseClass.

So, in your new article, you are off to a good start under the heading “Abstract Classes Are Interfaces”. But I fear that your subsequent sections “So Which One Should I Use?” and “An Evolutionary Design Case Study” don’t do justice to the topic. That said, by the time you reach your conclusion you have grasped an important point, and that is you can mix interfaces and abstract base classes to arrive to your desired solution, without selling your soul to either one or the other.

There are a few more MSDN articles that make interesting reading if you’re interested in some more theory, such as this one:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbcon/html/vbconimplementinginterfacesincomponents.asp

Another interesting article can be found here:
http://java.sun.com/developer/JDCTechTips/2001/tt1106.html
(Scroll down about halfway to the heading “ABSTRACT CLASSES VS. INTERFACES”.)

I tend to use lots of concise interfaces (large, clunky interfaces are not likely to be widely used, are they?) but it is useful to remember that classes that derive from abstract base classes can still implement interfaces, and partial abstract classes can be particularly useful too. So, an abstract base class can help you achieve polymorphism... contractually! :) Deciding whether to use an interface or an abstract base class (or both!) is not as black and white as your first article implies.

A final comment… Your statement that “the initial requirement was to output ... to the console” was just screaming Caution: Scope Creep Ahead! So your later statement that “an additional requirement surfaced ... to generate the report in XML” surely should have been anticipated? Or maybe you were simplifying your case study for the benefit of a succinct explanation?

Yes, designs do “tend to change over time as new functionality is added to the system” but doesn’t that highlight what makes us stand out from the overcrowded sea of developer-wannabes? Being able to anticipate what direction the design might take? We don’t only program to interfaces - we also design concise, flexible, usable interfaces.

Thanks for an interesting read, Scott.

David R. Williamson

# July 10, 2006 10:17 PM

scott said:

Thanks David; I really appreciate the time you took to give really constructive feedback.

As you rightly guessed the case study was simplified for the benefit of a clear and concise (IMO) example. Looking back though it does seem a little trite and contrived but I hope it does the job.

As I mentioned earlier in the article, I tend to favour a Test Driven Development approach when developing, so though I often foresee the direction of change in a system (or application) I try not to implement anything until a legitimate need arises; YAGNI - You Ain't Gonna Need It - to quote varios XP texts.

That said the focus of this piece was on internal enterprise applications where interfaces are public but not published and thus hightly mutable. I feel that the same evolutionary approach still applies when developing published interfaces though they have to be transformed with greater care and caution.

I have been known to (gradually) implement large scale refactorings specifically to transform the interfaces in the system to be more extensible. All in all I totally agree with you comments specifically: We don’t only program to interfaces - we also design concise, flexible, usable interfaces.

An excellent point. Thanks again for the feedback.

Scott X Dukes

# July 12, 2006 8:39 PM