In terms of updating the WordPress Widget Boilerplate (all of which is tracked in the develop branch), we’ve come a long way in terms of refactoring how it’s organized.
Thus far, we’ve:
- looked at how the WordPress Widget API provides an example of object-oriented programming,
- how we can use this API to determine object-oriented programming in other areas of WordPress,
- installed tools to help us evaluate the quality of the code,
- found errors that currently exist in the code in terms of modern programming standards,
- and began re-organizing the code base so that it fits with more modern practices.
Now we’re ready to start refactoring this code in a much more object-oriented manner.
So if you’ve yet to catch up with the previous posts (any of them, really), I recommend doing so because it’s going to take a little while to bring this up to date. There’s a lot of code to write an explain.
Let’s get started.
The WordPress Widget Boilerplate: Refactoring, Part 3
Arguably, the biggest problem with the Boilerplate is that everything is encapsulated within a single class.
Sure, there are some nice things like keeping our views separated from the server-side logic, but that’s about as far as it goes.
Other problems that exist just from looking at the code include:
- adding actions and filters in the constructor,
- having methods doing more than one thing,
- not having classes responsible for implementing things like registering dependencies,
- and so on.
In this post, we’re going to start the process of creating abstractions that we’ll eventually implement to break up the god-class-like nature of the Boilerplate as it stands.
Abstractions and Interfaces
Remember that abstractions and interfaces are different but are easily confused. Interfaces contain absolutely zero implementation. Instead, they provide a guarantee that any class that implements the interface will implement all methods.
Abstract classes, on the other hand, can have some functionality implemented in the abstract class while leaving the domain-specific code – such as loading stylesheets and JavaScript – to the appropriate method.
This will become apparent, if it hasn’t already, the further we get into this series. In the meantime – and as per usual – don’t forget to check out the develop branch to see where we stand with the code.
