Scott Dukes' Blog

Interfaces vs Abstract [Base] Classes Reloaded

scott — Fri, 07 Jul 2006 19:56:00 GMT

About a year ago I participated in a heated online discussion about the merits of Interfaces vs Abstract [Base] Classes. Justin felt that Interfaces weren’t worth the code they were written on, and I responded with their merits [in my opinion]. As always time and experience tend to temper my opinions on things.

Abstract Classes Are Interfaces

Reading Head First Design Patterns, I came upon the following quote:

“Program to an interface” really means “Program to a supertype”.

This means that using an Abstract Class is programming to an interface. I’m afraid both Justin and I were a little too literal in our interpretations of that statement. Martin Fowler recommends:

You should always use the most abstract interface or class possible in type declarations.

The important aspect to note is to use an abstraction; whether it be an abstract class or the interface keyword in C## or Java (hereafter referred to as an explicit interface). It means using an abstraction to decouple the implementation of some piece of functionality from its users (clients) thereby allowing the implementations to vary without affecting the clients. The choice of which language construct to use ultimately boils down to how we intend the implementations to vary (and even this choice can be changed later using Refactoring).

So Which One Should I Use?

Hristo Yankov referred me to the MSDN Library which has some guidance in Recommendations for Abstract Classes vs. Interfaces; specifically:

If you anticipate creating multiple versions of your component, create an abstract class. Abstract classes provide a simple and easy way to version your components. By updating the base class, all inheriting classes are automatically updated with the change. Interfaces, on the other hand, cannot be changed once created. If a new version of an interface is required, you must create a whole new interface.

If the functionality you are creating will be useful across a wide range of disparate objects, use an interface. Abstract classes should be used primarily for objects that are closely related, whereas interfaces are best suited for providing common functionality to unrelated classes.

If you are designing small, concise bits of functionality, use interfaces. If you are designing large functional units, use an abstract class.

If you want to provide common, implemented functionality among all implementations of your component, use an abstract class. Abstract classes allow you to partially implement your class, whereas interfaces contain no implementation for any members.

On the whole I agree with the guidance present, with one caveat: it assumes reasonable foreknowledge of both the future usage of your types and the evolution of their implementations. In practice this is seldom known or even knowable at design-time. In my experience, designs tend to change over time as new functionality is added to the system.

Disclaimer: I tend to favour XP style development practices (TDD, Refactoring, Evolutionary Design) over extensive upfront design.

An Evolutionary Design Case Study

A Simple Solution

As an example, consider the following case study of a recent project that I wrote to report the differences between versions of custom webservice proxy classes. The initial requirement was to output the differences between two proxies to the console; I used the following simple design.

The application compares the two proxies using the Compare() method of the ProxyComparer class, obtaining a ProxyDifferences instance in result. This class encapsulates the specific differences: methods added, changed, or deleted. The ProxyDifferences instance is then passed to an OutputGenerator object which generated a textual report of the differences.

The Plot Thickens

Later an additional requirement surfaced in being able to generate the report in XML instead - for use in the generation of an HTML report via an XSLT transformation. Now the purpose of programming to the interface is to [relatively] insulate the client [code] from changes in the implementation. In this case there was no abstract interface only the implicit interface of the OutputGenerator class.

In order to both implement the new requirement (XML output) and minimise the effect on the client I needed to introduce an interface abstraction for the OutputGenerator. The generation algorithm for textual output was sufficiently similar to that required for XML output [with a bit of work] for me to want to reuse it. I ended up refactoring to a Template Method [GOF] by turning OutputGenerator into an abstract class with concrete implemenations for the two generation mechanisms by means of an Extract Subclass [F] refactoring.

Coming Full Circle

A week or so later the need to generate both text (to the console) and XML (to file) simualtaneously arose. To minimise the effect on the client I needed to maintain the behaviorial contract of the interface while introducing the ability to generate one or more different outputs. The obvious choice was to introduce a Composite [GOF] OutputGenerator that could delegate to any number of contained OutputGenerator objects, and which shared the common OutputGenerator interface.

To do this I could make the Generate() method virtual and override it in the composite, but this seemed to go against the spirit of the Template Method [GOF] pattern, and the composite generation did not utilise the common generation implementation. I decided to introduce an explicit interface (IOutputGenerator) by means of an Extract Interface[F] refactoring on the OutputGenerator and have the CompositeOutputGenerator implement it.

This turned out to be a very effective and flexible solution which kept to the purpose of programming to the interface.

Conclusion

In summary, using either abstract classes or explicit interfaces satisfies the design goal of program to the interface. Often it is not clear which to use at inception, only as new functionality is added to the system does the choice become clear, sometimes even migrating from one to the other. The important thing to keep in mind is the purpose behind this guideline - minimise the effect on existing clients of the interface however it may be implemented.

References

[GOF] Design Patterns: Elements of Reusable Object-Oriented Software

[F] Refactoring: Improving the Design of Existing Code

Now that's cool! The Cold Heat Soldering Tool

scott — Fri, 29 Apr 2005 18:33:00 GMT

I found this on ThinkGeek: The Cold Heat Soldering Tool.

The Cold Heat Soldering Tool is a cordless tool that heats quickly and cools down nearly as fast. It creates the heat right in the proprietary tip material, making the tool 20 times more efficient than the average conventional soldering iron. The tip reaches 500ºF in less than 1 second for many types of joints and cools to the touch in a few seconds so you can put it away – without any waiting.

All this for only $19 (R115 excluding shipping). Gotta get me one of those.

Interfaces vs Abstract Base Classes

scott — Fri, 29 Apr 2005 09:17:00 GMT

There has been a lot of discussion on the value of Interfaces lately. Justin feels that Interfaces are not worth the classes that they are written on [1, 2]. I disagree with that statement in general, although I do see (I think) where Justin is going with this, and his argument does have merit.

Firstly, I think that some clarification is in order. I think it's important that the Base Classes be abstract, since a design based on Concrete Class inheritance has bigger issues to contend with than interfaces.

I know this had been said before, but I think it is important enough that it bears repeating: Inheritance [using Abstract Base Classes (which I'll refer to as Base Classes for brevity)] means "is a", whereas using an Interface means "behaves as ". Both Base Classes and Interfaces define a class interface or a contract for the class/implementor. Please note that these approaches are not mutually exclusive; they can be used separately or together. What to use depends on where you intend to have the class used.

Interfaces provide a common (and relatively independent) abstraction to handle completely disparate implementations, whereas a base class approach effectively ties you to a single implementation, limits re-usability, and results in a more brittle design. As I stated, I favor a hybrid approach with an abstract base class providing a reference implementation of the interface in question.

It also pays to look at why we even have interfaces at all; what is the purpose behind them? In a language that supports multiple inheritance (like C++ or Eiffel), interfaces have diminished value. It makes sense to define behavioral contracts using abstract classes which also provide a generic implementation of the behavior. In these languages multiple inheritance allows you to simply plug in functionality to any class that requires it, rather than having to create explicit implementations of an interface; in fact, this is, according to [McConnell], the preferred (safer) way of using multiple inheritance.

In languages that only support single inheritance (like C# and Java), or only interface inheritance (like VB6 - yuck!), Interfaces take on a much more important role. Using interfaces together with object composition allows the developer a similar ability to simply plug in functionality, giving some of the flexibility of multiple inheritance, whilst ensuring that the object models are kept (relatively) simple.

Ultimately it boils down to OOP fundamentals; it's generally a good heuristic (rule of thumb) to keep your class interface as small and cohesive as possible. The biggest risk in using Base Classes comes from the tendency to move unrelated behavior into the base class, as the implementations evolve, resulting in a less cohesive "interface". And whats more, it is easy to do. Sure, you run the same risk using interfaces, but it's not nearly as convenient for the developer, so it's much less likely to occur.

It is also tempting to ignore that behavioral aspect of objects and treat them simply as containers of data (like an in- memory representation of a database row) with methods related to accessing and/or changing the data. This defeats the point of OOP. An intrinsic part of object design is the behavior, and one of the purposes of OOP is to encapsulate behavior and data. And taking this a step further; just as the schema of database table defines the form of the data, an interface defines the form (or contract) of the behavior.

A classic beginner mistake is to use inheritance to provide similar behavior in unrelated classes. Lets look at an example (adapted from Effective C# by Bill Wagner ); consider the three classes below.

They obviously share the common property Name, but conceptually they are not variants of a common theme. Each one is a distinct entity and it would be both naive and dangerous to derive Employee, Supplier, and Customer from the same base class.

A better approach would be to create an interface (say IContactInfo) that specifies the common properties and have each class implement the IContactInfo interface.

I said earlier that interfaces provide a common abstraction to handle completely disparate implementations. This enables us to create methods that will handle any implementation, same or different.

public void PrintWelcomeMessage(IContactInfo info) {
Console.WriteLine("Greetings {0}", info.Name);
}

You could argue that a base class would provide the same flexibility, and you'd be right, for now. The advantage of using an interface comes in the future. Let us suppose that in the previous example we had created a base class called BusinessEntity containing common functionality; we could then have defined the above method as follows.

public void PrintWelcomeMessage(BusinessEntity info) {
Console.WriteLine("Greetings {0}", info.Name);
}

However, what if six months later we have a requirement that Employee needs to support remoting and consequently needs to extend MarshalByRefObject. Now depending on how we've implemented our base class this might be very difficult to do (without affecting the other classes). If we do affect the other classes, by making the change on the base class, there might be repercussions (errors) down the line. Basically it introduces a potentially unknown variable into the equation. By using an interface we can create a completely divergent implementation without affecting any other classes. This is concept is known as the principle of Orthogonality.

I would say that, as a general rule, if the consumers of your class are internal to your system it is safe to use base classes and refactor to interfaces as your design evolves. This echos a comment by Rivaaj Jumna who stated: " I tend to favor the interface driven approach to design, if only because I end up refactoring to interfaces at various intervals." This is, incidentally, also the purpose behind the Bridge Pattern; to "decouple an abstraction from its implementation so that the two can vary independently. "

If your consumers are external, possibly clients using your API, then I think it's safer to use interfaces unless it's absolutely necessary to provide the functionality that an abstract base class would provide.

In summary, the use of Interfaces leads to flexible and reusable designs. While abstract base classes do have immense value within a system, they are not a replacement for interfaces.

Fiddler 0.9.9

scott — Fri, 29 Apr 2005 07:09:00 GMT

This is a bit late, but I noticed that there is a new version of Fiddler out (0.9.9 released on 1 Feb 2005). For those of you that don't know, Fidder is a HTTP Debugging Proxy. It effectively catches all HTTP requests/responses on your system. It's quite simple to use and extremely helpful when debugging web applications.

I recently used it to inspect why IMHO wasn't functioning correctly at work (tuned out to be due to an (unresolved) authentication error with ISA Server). I have also used it in the past to inspect/debug remote scripting issues.

It is implemented using .NET 1.1 and "includes a simple but powerful JScript.NET event-based scripting subsystem" called FiddlerScript. FiddlerScript even has a syntax-aware script editing environment. Plus it's extensible; you can create your own custom Inspector Objects in any .NET language.

You can download it here. The Fiddler Script Editor is available here.

New Toy

scott — Wed, 27 Apr 2005 19:11:00 GMT

For the last few months I have been facing a user input irritation. I use my notebook both at work and at home. At work I have a Microsoft Wireless Optical Desktop Pro (which totally rocks), but at home I have to resort to using the keyboard and trackpad on the notebook (which sucks). So yesterday I went out and got myself a Microsoft Wireless Notebook Optical Mouse.

This is uber cool. Not only is it both wireless and optical (obviously), but it's extremely compact. Plus it has a very long battery life (well at least according to the brochure) - 3+ months on a single AA battery. The wireless receiver is USB and plugs into the bottom of the mouse when not in use, thereby disabling the optical sensor and conserving battery life.

All in all, I'm a much happier camper, plus it didn't break the bank. It cost a mere R230 ex VAT, which is cheap at the price.

How to you argue with stupidity like this????

scott — Mon, 25 Apr 2005 13:04:00 GMT

Warning: Rant about to commence.

At a recent daily status meeting the topic of our corporate firewall came up (one of the developers needed a port opened to replicate data to a remote server). A colleague of mine announces that he has a buddy at Redhat who can help since we are using an "Apache" firewall.

Apart from the obvious security issues (letting a stranger tinker with our firewall), and the fact that our own Systems Administrator is perfectly capable of getting this done; there is no such thing as an Apache firewall.

Since I know that we use a PIX firewall with ISA server as a proxy, I responded with: "Dude, Apache is a web server". To which I received an extremely frosty "No! It IS a firewall".

How to you argue with stupidity like this????

Bookpool Rocks!

scott — Mon, 25 Apr 2005 12:53:00 GMT

Yay! My most recent book order just arrived. This is the first time that I have ordered on Bookpool and I must say that I'm impressed. Not only were they cheaper than Amazon.com, but a mere 15 days after I placed my order the books where here.

These are the books that I ordered:

I've been extremely keen to read both of these, especially Applying UML and Patterns. Martin Fowler recommends it as "the best book to introduce ... the world of OO design". The 3rd edition also has a greater focus on agile methodologies (this book proposes using the Unified Process as a methodology) to be used in conjunction with UP. Like Fowler he also suggests using "UML as a sketch" with ties into the ideas presented in Scott Ambler's Agile Modeling.

As for Effective C#; it follows in the foot steps of Scott Meyer's excellent Effective C++ and More Effective C++. Both of which offer a multitude of insight into improving your C++ code. I hope this book adds the same value that those do.

I'll post some reviews (assuming I'm up to it) once I'm done.

.Net: The beginning or the end [of development as we know it] ?

scott — Tue, 19 Apr 2005 10:00:00 GMT

Okay, now that I've got your attention with a snappy headline...

I found some interesting viewpoints on development using .NET (personally I'm sold, but it's always good to view both sides of the coin).

First off we have Mark Russinovich (Windows Internals expert of sysinternals.com fame) arguing that .Net is too bloated in The Coming .NET World – I’m scared.

In rebuttal Ken Henderson, (Sql Server Guru) reckons that .Net is the best thing to hit software since OOP.

Draw your own conclusions?

Durban Patterns Group: Session 3 Reminder

scott — Wed, 30 Mar 2005 07:09:00 GMT

Just a quick reminder.

The next patterns session will be held on Wednesday, 6 April 2005 in the Conference Room at Marriott-at-Kingsmead, Kingsmead Office Park. The session will start at 17:30 sharp and will run for approximately 2 hours.

The patterns under discussion will: Iterator (p. 257) and Template Method (p. 325).

Please RSVP on this thread.

Free Profiler for .NET

scott — Wed, 30 Mar 2005 07:05:00 GMT

Reading an article, comparing the performance of the Enterprise Library Logging Block vs log4net, discovered the following gem: DevPartner Profiler Community Edition.

If you've ever used DevPartner Studio, you'd have seen the fully fledged version of this product, but as a free download this will do hey!

It is available here (42Mb).

Update: The article that I was reading was this one.

An Addition to your Software Development Dictionary

scott — Thu, 17 Mar 2005 08:34:00 GMT

[via Martin Fowler]

(Here's an addition to your dictionary.)

Detestable (adjective): software that isn't testable. (from someone at the Sydney XP group, whose name I sadly forgot.)

What Great .NET Developers Ought To Know

scott — Wed, 02 Mar 2005 11:33:00 GMT

I found this great post on Scott Hanselman's blog. I found it to be a real eye opener and a very valuable measure of how much and (in some areas) how little I know. I reckon its a must read for anyone whose serious about developing in .NET.

Session 2 Reminder: Thursday, 3 March 2005

scott — Wed, 02 Mar 2005 11:28:00 GMT

Just a quick reminder that the next patterns session is on Thursday (3 March 2005) evening at 5:30pm at in the conference room at Marriot-at-Kingsmead.

The Patterns under discussion are: Decorator and Composite.

See the our group for more details.

Enterprise Library Released

scott — Sun, 30 Jan 2005 14:00:00 GMT

The Enterprise Library has finally been released. Sweet gorrilla from manilla. :-) I've been waiting for this for ages. You can get it here.

Durban Patterns Group: Session 1 (Reloaded)

scott — Mon, 17 Jan 2005 09:47:00 GMT

The first Durban Patterns Group meeting flopped due to lack of attendance (bad time of year I guess), so its time to try again.

It will be held on the Thursday the 20th of January 2005, in the conference room of Marriott-at-Kingsmead, Kingsmead Business Park. Start time is 17:30.

Everyone attending the first session is required to have read up on the Factory Method [1,2] pattern. I envisage roughly a 1 hour (2 hours max) session of discussion and whiteboarding. It might be useful if everyone attempts to implement an example of the pattern to be covered in the session to get a feel for it in application, other than just reading about it.

Please note: You will need a copy of [GoF] (print/electronic) in order to do the readings between meetings. If you require one, contact me and we will see what we can do.

Update: I have set up a group for news, events and discussion about the group. It is accessible at http://groups-beta.google.com/group/Durban-Patterns-Group