In the previous post in this series, I walked through:
- the basics of abstract classes,
- how to implement them,
- and provided working code examples.
And though I think understanding abstract classes are key in laying a strong foundation for object-oriented programming, I often see that it can be confusing when it comes to comparing them to interfaces and knowing when to use them.
Abstract Classes and Interfaces
So in this post, I’m going to share:
- a quick refresher on what interfaces are,
- what abstract classes are,
- and then how to know when to use one over the other.
This shouldn’t be a coding intensive article, but it should help know when to write code of a certain type to help better organize your projects.
Recall that when it comes to interfaces, we also use the term “programming to an interface” with the idea being that the interface defines the methods that an class must implement to fulfill the “contract’ with said interface.
The code used to demonstrate a basic interface was:
But remember, the purpose of the interface is not to define after the code has been written. Instead, it’s a tool used to design what classes should implement should they follow a certain paradigm or should they require a certain set of functions.
That is, if you’re going to be designing a set of classes that work with caching, you don’t write the classes first. You write the interface first, and then the classes implement said interface.
The idea is that any class implementing the interface will be guaranteed to have those functions.
2. Abstract Classes
Abstract classes, on the other hand, allow us to do two things:
- implement functionality that can be used by subclasses,
- implement method signatures that subclasses must implement.
This might read a little incongruent at first, but consider this:
When you have a class of a certain type that will have consistent functionality no matter the subclass, the functionality goes in the abstract class. When other methods need to have their implementation of a method, then you simply provide the method signature and mark it as abstract.
Here’s an example from a previous post:
Now, this gets us all caught up on the previous examples and the previous things we need to focus on regarding interfaces and abstract classes, but for some, this still doesn’t provide much clarity.
Specifically, this still doesn’t answer the question: How do we decide when to use an abstract class and when to use an interface?
On the surface, it may sound a bit confusing, but there are a few things you can use to help make the decision.
When Do We Use Each?
Remember that when it comes to object-oriented programming, we can break it down into three distinct ways:
- Classes represent a thing. You can consider these a noun.
- Attributes or properties are like adjectives. They describe the object or something the object may hold.
- Methods or functions are like verbs. They describe what they object can do.
Now when it comes to an interface, think about what the interface does: It describes, without implementation, what an object can do. And when it comes to an abstract class, it describes what an object is during runtime.
In other words, a good rule of thumb is that if you need to provide a set of behaviors for an object, an interface is a way to go. If you need to describe what an object is, then use an abstract class.
For abstract classes, I’d also take this a step further and say that it helps to describe a base level of data that describes an object or what it might store in addition to a base level of functionality.
Got An Example?
As with most of the content in each of these posts, I try to give examples even if it’s not specifically done in code. Perhaps this will help explain it even more:
- Interfaces have no implementation. They only guarantee what a class will do.
- Abstract classes should have a base level of implementation. This should represent what a class can hold and do but are not complete. They require a bit more implementation from the subclass.
When you’re working with object-oriented code, I hope this helps to provide some guidelines as to when to use what. If not, don’t hesitate to leave a comment (something members do have permission to do :).
Furthermore, we’ll see this in practice when we get to writing object-oriented code (most notably for WordPress, but not always).