In web development, I think many who here the term “interface” or who talk about “creating an interface” usually refer to how the page, site, or graphics will look.
And that’s completely normal because when the majority of outlets – presentations, news, articles, media, etc. – talk about the way something looks as it relates to technology, they always talk about its interface.
Not to mention, it is the correct term.
But when it comes to object-oriented programming, the idea of creating an interface is a bit different. Rather than referring to the way a program looks, you could say that it has more to do with how it functions.
Even that isn’t necessarily the proper definition, but it’s close enough. If you’re an experienced programmer, then you’re likely already familiar with this idea.
But if you’re someone who’s just getting into object-oriented programming (specifically using PHP in the context of WordPress), then maybe this will help when designing the architecture of your next project.
Creating An Interface
Before I go any further into my words, here’s a textbook definition of “interface” straight from Wikipedia:
In object-oriented programming, a protocol or interface is a common means for unrelated objects to communicate with each other. These are definitions of methods and values which the objects agree upon in order to co-operate.
If you’re familiar with object-oriented programming, this doesn’t sound all that bad. But if you’re new to the paradigm, then it likely just reads like jargon.
I mean, when you jump into learning a new concept and they are already describing something as a “protocol” by which objects communicate, it’s easy for eyes to glaze over.
It makes you want to move on to something that actually makes the computer do something, right?
Here’s the thing, though: Interfaces are very useful concepts in object-oriented programming, and I wish we saw them more as it relates to building things for WordPress.
What’s the Purpose of an Interface?
Think of it this way: When you define an interface, you are writing code that other code (namely, classes) must enforce.
You’re setting up a contract that says:
If you choose to implement this interface, then you promise to define this functionality.
Normally, this is where textbooks veer off into the land of unrealistic examples. By that, I mean they usually start throwing out an interface for something like a
Dog and then giving it methods like:
And so on. But the actual number of times you’ll be programming a dog, at least as far as our industry is concerned, are pretty slim.
Instead, what if we were to define an interface for something like a
post_manager? If we were to do that, then what are some things that a post manager might do?
Perhaps it would:
- `set_status_of( $post )`
- `publish( $post )`
- `delete( $post )`
- `autosave( $post )`
And so on.
So that’s nice and all, but what do we really gain by having an interface that a class may implement?
There are some different reasons to implement an interface. I can’t cover them all because I’ve not experienced them all; however, I’ve worked in systems large enough to know that if you have many classes with similar functionality – like some type of message dispatchers – then they will likely have the same interface.
But that sits at a particular level and is more detailed than this post warrants. Instead, interfaces can give us huge gains when it comes to making our code testable.
Instead, I want to touch on something that’s more practical. When it comes to writing unit tests and making sure that our software is working as expected, it can become very complex when all of the parts begin to form a big ball of mud. (Sometimes you read this as classes having a high-level of coupling, but that’s another topic for another time.)
Think of it this way: When we write code for WordPress, we have to register out classes and/or functions with the hooks provided by WordPress. So when we want to test our code that will run within WordPress, we need to load WordPress, right?
That’s a lot to do just to test a bit of functionality. And though there are very useful tools available for writing unit tests for WordPress (which I’ve talked about before), there are other ways you can test the logic of your code (or at least some of your code) without having to tap into any hooks.
And that’s using an interface.
To be more specific, if we define an interface for what our class will do, then we can write mock classes – that is, classes that are meant to represent the actual functionality that will hook into WordPress – that use the same logic, but can operate on test data.
From there, we can then write unit tests around those mock classes. If the tests pass and we’ve architected and implemented our interfaces correctly, then we should be able to exchange out the mock classes with our actual implementation and be more confident that we haven’t broken something.
This Is a Single Example
Everything above is just a single example. It’s not meant to be all-encompassing, it’s not meant to be an in-depth tutorial, and it’s not meant to serve as an ultimate primer on unit testing.
Instead, it’s intended to help by providing new programmers a conceptual model for creating interfaces. There are entire books written on this subject (I’d link a few, but there are so many – perhaps one good place to start may be here).
Further, this is one of those topics that will go a long way in improving the integrity of a system the longer you work on it. So the next time you opt to commit to core, run the associated unit tests. Or the next time you land a large job from a client, look into creating interfaces and writing unit tests for them.
If you’re already familiar with the skill, then you know it will definitely help to improve maintenance of the project as you continue to build it out over time.