No, Using Interfaces (or Abstractions) Alone Does NOT Mean You’re “Object Oriented”

Posted on by

Since I’ve been dealing with a lot of Java and now C# code over the past few years, I’ve noticed one thing: Java and C# programmers love interface classes. In fact, it seems that most Java and C# programmers think that they cannot have a concrete class that does not inherit from some interface.  I was curious about this in a lot of the C# code I’ve had to deal with so I asked why.  The answer I got was “that way we are using abstractions and encapsulating things.”

Wrong.  Just, wrong.

“Why not smart guy?” you might ask.  First off, let’s look at some definitions.  An interface is used to define a set of functionality that derived classes must implement.  Interfaces can only contain method and constant declarations, not definitions.  An abstraction reduces and factors out details so that the developer can focus on only a few concepts at a time.  It is similar to an interface, but instead of only containing declarations, it can contain partial definitions while forcing derived classes to re-implement certain functionality.

With these definitions, we see that an interface is just a language construct.  It really just specifies a required syntax.  In some languages, they are not even classes.  What went wrong?  Well, historically, it appears that people got the wrong idea that an interface splits contracts from implementations, which is a good thing in object-oriented programming because it encapsulates functionality.  An implementation does not do this, IT CAN’T.  Remember, an interface simply specifies what functions must be present and what their returns are.  It does not enforce how computations should be done.  Consider the following interface pseudo code that defines an imaginary List with a count variable that specifies how many elements are in the list:

interface MyList
{
  public void AddItem(T item);
  public int GetNumItems();
}

So, where does the above enforce a contract that each added item will increment an internal counter?  How does it FORCE me as a programmer to increment an internal counter?  It doesn’t; it can’t.  Since an interface is purely an empty shell, I as a user am free to do as I like as long as I just follow the interface definition.  If I don’t want to increment an internal counter, I don’t have to do so.  This does not really fulfill the object oriented dependency inversion principle (DIP), which states (as quoted by Wikipedia):

    A. High-level modules should not depend on low-level modules. Both should depend on abstractions.
    B. Abstractions should not depend on details. Details should depend on abstractions

In common speak, this basically means that we can focus on high-level design and issues by ignoring the low-level details.  We use abstractions to encapsulate functionality so that we are guaranteed that the low-level details are taken care of for us.  Consider the following pseudo code abstract List class:

abstract class MyList
{
  public void AddItem(T item)
  {
    AbstractedAdd(item);
    this.internalcounter++;
  }

  public int GetNumItems()
  {
    return this.internalcounter;
  }

  abstract private void AbstractedAdd(T item);
}

With the abstract class, we actually have a contract now that fulfills the DIP.  As an abstraction can contain a partial definition, we have a defined AddItem() function that calls an abstract internal function but also increments the internal counter.  While it is a loose guarantee, we are guaranteed that the internal counter is incremented every time AddItem() is called.  We now do not have to worry that the abstraction will take care of the item counter for us.

What appears to have happened over the years is that student programmers heard about things like the DIP and warped it to think it means that every class must have an interface (when they mean abstraction), whether or not the class is designed to be used only once.  This I think can be attributed to teachers not doing a good job at differentiating interfaces from abstractions and not really teaching what encapsulation means.  Thinking like this also led to the second problem.

Secondly, a lot of people did not get the message that “all software should be designed to be reusable” got discredited after the 1990’s when it turned out that this philosophy needlessly complicates code.  Trying to design code like this ends up with a huge Frankenstein’s monster that is hopelessly complex, prone to errors, and really does not face reality that being a Jack of all trades means you’re a master of none.  This created a somewhat tongue-in-cheek object oriented principle called the Reused Abstraction Principle (RAP) that says “having only one implementation of a given interface is code smell.”   We refactor code to pull out duplicate functionality because it helps to keep the code base small.  It improves reliability because having a single implementation of potentially duplicated code means we don’t have several duplicate implementations that may differ in how they are done.

However, this does not mean that code HAS to have duplicated functionality “just because.”  If your problem domain only has one instance of a use case, it really is OK to just have a single concrete class that implements this.  Focus on a good design that encapsulates the functionality of your problem domain, not worrying that every piece of functionality must be reusable.  Later on, if you problem domain is expanded and you end up with duplicate functionality, refactor it and then have an interface or abstract class.  Needless use of interfaces and abstractions just doubles the number of classes in your code base, and in most languages abstractions will have a performance penalty due to issues like virtual table lookups.  Simple use of interfaces and abstractions does not make you a cool kid rock-star disciple of the Gang of Four.

Leave a Reply