Interface Magic

I’ve been a fan of interfaces (the programming kind) ever since I started using them as part of COM programming, sometime in 1995.  At times, I went overboard, creating an interface or maybe two for every class I wrote.  In the COM days, you really needed to worry about this, because it was the way to communicate between dlls and exes without worrying about nasty linkage and header file issues (i.e. basic C++ programming B.S.).

Now that I’ve been writing more of my own code as a lone programmer, I’ve gotten a bit mellower about interfaces.  I’ve been writing smaller projects and I don’t have to worry about other people using my code.  However, the other day, I found that creating an interface was just the quick fix I needed to save myself from copying and pasting a bunch of code three times.

I had already created three different classes that were just data holders with unique data.  I only needed these three, so doing some code duplication didn’t bother me (we all have a tolerance and I hadn’t reached it just yet).  But, then I needed an output routine that would have to traverse the data for each instance of all three classes and I realized that creating one simple data access interface would let me write just one routine.  Also, later, I could use the same interface to clean up the original code and make it more concise, if I felt so inclined.

On a previous project, I had designed a set of interfaces to cover the functionality of some very different classes that needed to be selected and manipulated on the screen.  When a colleague stopped by and wanted to write a new uber-manipulation tool, I thought for a moment and told him to implement the common Control interface that I used for my other objects and he’d be halfway done with his job.  It also meant that I didn’t have to suffer through someone else hacking away at my already working, but somewhat complicated selection code.

One other thing that I (and my coworkers) did at a previous job was to give every class a public and a private interface.  All communication with the classes was done through the interfaces and not through a class directly.  Remember that the other benefit of interfaces is the clear indirection between the communication layer (how you interact with the class) and the implementation layer (how the class responds).  It’s very easy to get lazy with public and private tags to access data, but many times we get a little lazy and let other code see our internal structure.  Then, when we find out it’s too slow or needs slightly different functionality, we have to change the calling code to change our internals.

For me, one of the great benefits of interfaces is the ability to reuse code that calls the interface, allowing me to worry about the new functionality without having to rework the old (i.e. I don’t need to accomodate a new class in the old code because I’m calling interfaces instead).  Interfaces can allow my classes to masquerade as several different kinds of objects without the need for complicated inheritance trees.  I often find that creating a new base class to handle a particular interface can be just the ticket, too.  One of the best things about software is its malleability.  It often pays to rework a few things and add some interfaces, even after the fact, to make the code easier to understand, use, and reuse.