WordPress Widgets: Refactoring, Part 3 Arguably, the biggest problem with the Boilerplate is that everything is encapsulated within a single class. So let's change that with abstract classes.

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.

WordPress Widget Boilerplate: The Develop Branch

Thus far, we’ve:

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.

⚠️ Hey, Wait!

Thanks for your interest in this article! Note that it's available to members only. If you'd like to review this (and have access to all previous and future articles), check out the membership benefits.

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.