We’ve implemented a significant amount of changes to the WordPress Widget Boilerplate. If you’ve not been following along, I recommend starting at the beginning of the series and catching up.
If, however, you’ve been following along and you’re also running some of the code quality tools that examine the state of the project, then you’re going to notice a handful of errors in the console.
Normally, this is the point where I recommend paying attention to what it shares and then fixing whatever it reports, but we’re not there yet.
For example, some of the errors that our tools are showing right now are based on the fact that we have unused variables. Of course, that’s the case, though, because we haven’t started building a widget.
But there are still a few concrete classes we need to implement.
The WordPress Widget Boilerplate: Refactoring, Part 4
One of the problems that still exist in the code as it stands right now is that the widget’s constructor is registering functions and this isn’t a good thing.
The purpose of a constructor is to set the values of properties of the class, not to implement any type of logic. This is for a few reasons:
[restrict paid=”true”]
- it creates strong coupling or dependencies among classes in the project whenever a given class is instantiated,
- it introduces business logic into a function that isn’t intended to contain said functionality,
- it makes it difficult to test a class in isolation.
The way to handle this is two-fold:
- add a Registry that we can use to register classes in the application (and pass them around with as few dependencies as possible which I’ll explain later),
- create subscribers that can handle the business logic on a hook-specific basis.
Over the next three posts:
- we’ll look at creating a Registry,
- how we can introduce it into the bootstrap file,
- and then look at creating subscribers for each of our functions (which shouldn’t be too hard given what we did in the previous post and what we’re doing in this post).
Create The Registry
Before writing the code for the Registry, it’s important to note what it’s primary purpose is. Simply put, the class is meant to contain a reference to any class that’s, ahem, registered with it.
This is done by passing a reference to a given object to a function and also binding it to a key so that we can easily retrieve it later.
Initial Considerations
But there are some things to consider. For example:
- if an object already exists within the registry for a given key, then we need to throw an exception
- if a user tries to grab an object from the registry with a given key, then it should throw an exception
Of course, it doesn’t necessarily have to throw exceptions. Instead, it can also display error messages, return null or empty values, or whatever you choose.
Secondly, the registry needs to be able to return a list of all of the subscribers that are contained within it so that they can be registered with WordPress (which is what we’re going to see in the next post).
To do this, though, we need to make sure that it supports all subscribers and this is where the notion of the AbstractSubscriber from the previous post comes into play. That is, as long as a class is a child class of that class, then we’re okay.
Creating the Registry
With that said, let’s plan out the following:
- We’ll create a Registry class and place it in a Utilities namespace (and thus directory) if it doesn’t already exist in your work.
- We’ll have the registry maintain a reference to all of its objects in an associative array.
- We need methods to add and get an individual subscriber and then one to retrieve the list of entire subscribers.
The stub for the class will look something like this:
Next, we can define the basic property, an array, and initialize it in the constructor:
After that, we can create the add method. Remember that in my implementation, I’m opting to throw an exception if a key is already defined, but you don’t have to do that.
Similarly, the get method will return a reference to the instance of an object identified with that key. If the key is not set, it will throw an exception. If it is set, but no object exists, then we’ll return null.
Finally, we need a method to return all of the registered subscribers. In a future post, the use for this will become much more apparent but for now, note that we’ll create an array of any class that is an instance of the AbstractSubscriber class and then we’ll return the filtered array.
At this point, we have the full class (complete with documentation):
Now we need to add it to the bootstrap of our plugin.
[/restrict]
Before The Bootstrap, Though
As mentioned earlier in the post, we need to add this to the bootstrap of the plugin. To do this, though, we need to define our own filter so that we can easily pass the registry around the rest of the plugin (when the time comes to do that).
Before we do that, though, it’s important to make sure you’ve got a good handle on the Registry we’ve just created, that it fits into the plugin and that you’re tracking with the develop branch that we have thus far.