Project Management

Interface Vs. Abstract Class

From the Agile Analysis and Design Blog
by
These are my thoughts on how best to process requirements into development activities that allow technical teams to align with business value. This includes requirements analysis, design qualities, best practices, and patterns of every kind.

About this Blog

RSS

Recent Posts

Interface Vs. Abstract Class


Categories: Language Idioms


Interfaces versus Abstract Classes

I teach developers things like Design Patterns, Test-Driven Development, Refactoring, and the like.  One question that often comes up when implementing a design in a language like Java or C# is “should I use an Interface type or an Abstract Class?”  I have an opinion on this, and I get asked this so frequently that I thought a blog entry would be useful.

This is related, by the way, to the question “should Interfaces be named using the initial I convention, or not?”  I initially said “no, that creates design coupling.  Why should clients know or care whether something is an Interface, Abstract Class, Delegate, Event, or any other type?”  Now I feel differently about this.

To answer both questions, we have to acknowledge that the Interface type, introduced (at least in my experience) in Java and then later supported by .Net, was not created (as many supposed) to compensate for the lack of multiple inheritance.  Multiple inheritance was eliminated for different reasons (that I’ll perhaps blog about sometime) and was not thought of as a “loss” to Java.

No, the Interface type was introduced to accomplish two different things:

  1. To create polymorphism in a system, and
  2. To mark a class as a participant in a framework service.

Polymorphism

Polymorphism literally means “many forms”, and we generally mean “many forms of a behavior” in software.  If you establish an Interface for, say sending data over a connection, then implement this interface in a number of classes each of which does this a different way, then instances of these classes can be up-cast to the Interface type making them appear to be the same.  The behavior then will vary depending on which is being used at a given point in time.

Of course, you can do this exact same thing using an Abstract Class, which is what leads students to ask the “which one” question in the first place.

Participant Flags

But an Interface can also be established by a framework service, and any class which implements it can participate in that service.  IComparable , for example, means the built-in sorting service of, say, .Net, can be used to sort instances of a given type.  Serializable is another example, making it possible to use the built-in mechanism in Java for serializing an object that implements it.  This is virtually always done using an Interface, because you might need to make a class capable of participating in more than one of these built-in services.

So my answer is this: if your purpose is to create polymorphism, use an Abstract Class.  If there are any redundant elements in subclasses, or if any arise in the future, you can easily eliminate said redundancies by moving them into the base (Abstract) Class.  You cannot typically do this with an Interface.

If, on the other hand you need to mark a class as a candidate for interacting with a provided service (either from an existing framework, or something you provide) then use an Interface type.  Whether you use the “I” naming convention is not particularly important to me, but I’d say be consistent.  If the services already exist and use this convention, it’s probably best to stick with it when you create your own, and vice-versa.

 

Posted on: May 03, 2021 03:19 PM | Permalink

Comments (5)

Please login or join to subscribe to this item
Hello,
interesting topic, question. Thanks for the explanation.

An abstract class can implement a behavior/logic while interfaces can't. Adding, java class can extend only one abstract class versus extending multiple interfaces. In general my idea is that Interfaces are used to design an idea (framework) while abstract classes are use it implement, part of it, broader, common, known logic/architecture.

Dear Scott
I would very much like to be able to participate in the debate on the theme that you brought to our reflection
I know nothing about software development :-)

Tiago: Not a bad point. However, that would argue against the "I" convention in interface naming, to me, because I'd like to be able to take something that started out as an interface, and change it to an abstract class later when implementation grows, and not have to maintain existing client code.

Luis: All are welcome to participate, no matter your background or interests.

Great article.Thanks for sharing.

Please Login/Register to leave a comment.

ADVERTISEMENTS

Love can sweep you off your feet and carry you along in a way you've never known before. But the ride always ends, and you end up feeling lonely and bitter. Wait. It's not love I'm describing. I'm thinking of a monorail.

- Jack Handey

ADVERTISEMENT

Sponsors