A common design pattern for WordPress plugins is to have one “main class” that implements the singleton pattern. This pattern is called the “God Class” and it loads all of the other classes the plugin needs as well as instances of those classes in properties of that class. I’ve utilized this anti-pattern, because it accomplishes a job and often is the best option for codebases that support PHP 5.2. But it’s not nearly as efficient as dependency injection to achieve a similar outcome.
The advantage of an implementation of the “God Class” anti-pattern is that you only need one singleton. Also, it’s easy to get those instances of the other classes via the one main class singleton. Here is an example of that pattern:
This works, I’ve written plugins like this. But, there are much better ways to do things. This pattern came about to avoid using globals singletons, both of which are considered bad practice. And yes, those two vague rules, are, in general right.
And yes, I get that legacy projects have to keep supporting a version of PHP that is almost a decade out of date and provide backward compatibility. But for new plugins or code for custom site development, there is no reason to follow this out of date pattern. It’s inefficient and inflexible.
In this article, I will talk briefly about why it is inefficient and ways dependency injection make it more flexible and more testable. I previously wrote about dependency injection, in the context of database abstractions. This article will take that concept further in terms of structuring plugins.
Please keep in mind all of the example code in this article, from here forward is written for PHP7. If you’re working on a plugin for release, or your server doesn’t support PHP7, all of this will work if you get rid of the return type declarations. I like return type declarations because they make code more self-documenting and improve performance. Using them in this tutorial will help you and your IDE understand the code faster.
Why The WordPress God Singleton Is Bad
In the example I showed above when the plugin is active, so is every single class it might need. That means before continuing, PHP needs to instantiate every one of those classes and store them in memory. Any database queries, API calls, or other logic that runs when they are instantiated happen.
That means if you need two of those classes for the current HTTP request, all of them are loaded. If you need none of them, all of them are loaded. That’s inefficient.
A good thing about this anti-pattern is that because the other classes don’t use singletons we can still create new instances of those classes and pass other values into their constructors. That’s good, except this type of architecture doesn’t really support classes that take different arguments in their constructors. This makes your classes less flexible to the point you might as well have just used a bunch of individual singletons. A class where each instance is identical to any other instance is a good use for the singleton pattern or for a class with all static methods. That’s easier to use and allows for lazy loading.
Lazy Loading FTW
One good thing about singletons is that the class isn’t instantiated until the first time it is used. This is an example of lazy loading. If it is never used, then it is never instantiated and no memory is consumed.
Singletons are one way to implement lazy loading, but they reduce flexibility.
Let’s imagine you were creating a plugin that needed to display recent posts, and recent products — stored in the post type “product”. I would create a “Posts” class that provided a reusable system for building WP_Query objects and getting the posts from the query.
Here is a basic example:
With this class in place, I could make a class that could return arrays of posts for each of the two post collections I need:
This class will lazy load objects of the Posts class. In addition, since it stores the found posts, I can reuse it twice in the same session without extra queries or object instantiation.
That’s pretty good, but it’s not scalable. If I need a third collection, I’m going to have to make another property and method. If I need 10 different post collections, it’s going to get messy. Very quickly this method goes from being a useful abstraction to a copypasta monster. It’s not a system at all really.
Before improving on this, let’s remember what is good about this. It avoids having to use a god singleton that would do all of these queries for every request, whether they were needed or not. These objects and the underlying queries or cache calls are only run when needed.
This class also provides access to collections of posts anywhere in your project. Using a static class like this is one solution I suggested in an article for problems of cross-cutting concerns.
First A Factory
The Posts class I showed above is a good wrapper for WP_Query, but it’s kind of annoying to use. Yes, I want all of the arguments of WP_Query to be useable, but at the same time, I’m most likely going to need to set posts per page, and post type(s). I don’t want to change this class because it’s useful, but a factory for creating objects of this class with more flexible arguments would be really helpful. In addition, that factory might be a good place to add caching later.
A factory is a class that constructs other classes. Here is an example that we can use for creating objects of the posts classes more easily:
Now I have a more obvious and more useful way to create a Posts objects. That’s nice, but it’s going to become especially helpful in the next step.
Moving To Dependency Injection
The scenario we are working with here is a plugin that displays recent posts and products, with flexibility to use different post collections later. There may be classes for using these post collections in widgets, shortcodes, REST API endpoints — really anything. The point is to provide a reusable and efficient way to provide arrays of posts to other classes that can format or store them in some way.
What I am saying in more abstract terms, is we want to make the display layer take the post collection as a dependency. The class for the display will not be responsible for finding its own dependencies, they will be provided to those classes.
Here is a before and after example of using dependency injection for a shortcode:
In this case, this class is in violation of the single responsibility principle. It adds a shortcode, does a database query and prints content to the screen. If I wanted to do any of those three things, without the other, I couldn’t. I don’t even have a good way of just calling this as a function without the shortcode.
But in our scenario, we have a way to create a post collection, and we want to be able to show that collection in a variety of ways. Here is one way to use both the post collection and the template for the view as dependencies:
This allows us to reuse that template in a different view, such as a widget, or with a different post collection. You could refactor this class into an abstract class for shortcodes or even a shortcode factory.
So even though this class uses dependency injection, it’s got a major shortcoming — the query is run when the shortcode is added. That’s not efficient at all.
We could go back to the lazy loading example I showed before, but I already explained why that isn’t scalable. It’s also not very testable.
Automatic Dependency Injection
In most modern PHP MVC frameworks, you can type hint an argument in a method of your controller and the framework will provide that dependency auto-magically. For example, in a Laravel controller, you can type hint Request and it just automagically provides the current Request object. This is because of Laravel’s dependency injection container.
WordPress isn’t an MVC framework, and I don’t think it is wise to try and force that pattern on WordPress. But creating a limited dependency container in a case like in the scenario that we are discussing is quite useful.
Let me show you how simple that can be using a PHP-DI, and open source project for automatic dependency injection in PHP. First, you will need to install it in your project. Presuming you are using Composer, simply require it and its optional dependency that allows for lazy loading:
PHP DI is really well documented, but I want to provide an example of how to create the container and use it to lazy load the post collections into shortcodes.
The first thing we need is a simple class to create the dependency container and make it available to the app:
Take a look at the “buildContainer” method. This is where we construct our dependency injection container. We are making two objects, both of which are lazy-loaded using our PostsFactory to provide post collections.
Let’s look at how they would be implemented to make our shortcodes with the ability to define each shortcode in a single line.
This would be set up like this:
As you can see, to add another shortcode, we can add one line to this array, with the tag and template path. That’s it. 3 shortcodes, 100 shortcodes, it’s the same and only actually using the shortcodes cause the Post class to be instantiated and the resulting queries to run. Those objects are reusable throughout the application.
To illustrate this point and show this same system used for dependency injection, let’s create one more implementation of the same container. In this example, we are going to bypass the WordPress theme system in select cases and just return one of our views instead on certain URLs.
In this example, I am hooking in at parse_request, a very early hook and seeing if any of our routes match and if so, calling a class called Controller to create the view. That class is more of a stub to show the dependency injection, but I will let you work with it to create a view.
If I was doing this, I would probably use FasteRoute for anything more complicated, but my simple router shows the concept. Also, I would be very suspicious of trying to make WordPress into an MVC framework, even though this isn’t a bad start.
Flexibility and Efficiency Achieved
I hope this article has helped you get a better understanding of dependency injection, as well as helped you understand the pitfalls and benefits of using it. Like all concepts of object-oriented programming (OOP) you shouldn’t use them because they are established principles. You should use them because they solve a problem, and you currently have that problem.
More importantly, I hope I’ve helped you think about code architecture in a way that will help you design code that needs minimal work. If you need another post collection in this system, you add a few lines of code to the container, but you don’t rewrite what it uses underneath. If you want to expand this container to do more than work with posts, you’ll need a bit more new code, but you shouldn’t have to make major changes to existing code.
That is what good OOP is really about — maintainable systems. Maintainable systems can be added to without any major refactoring and that’s what this provides.
Josh Pollock
Josh is a WordPress plugin developer and educator. He is the owner and a developer for CalderaWP, makers of Caldera Forms, a different kind of and Ingotthe native WordPress A/B testing solution.
The post Using Automatic Dependency Injection For WordPress Development appeared first on Torque.
