I’ve had a few conversations with various friends and others on Twitter about the notion of global variables in programming languages. For those who are new to programming or who are unsure as to why they are bad:

The use of global variables makes software harder to read and understand. Since any code anywhere in the program can change the value of the variable at any time, understanding the use of the variable may entail understanding a large portion of the program.

This isn’t to say they don’t have their use, but if you’re interested in object-oriented programming (especially in a WordPress setting where you’re going to be using PHP), then it’s important to understand some better alternatives than global variables.

That is, there are ways to work with passing data around your application without the need for global variables. And one such way is the registry pattern.

The Registry Pattern in WordPress

First, note that design patterns transcend any given particular pattern. As long as a language offers the concepts of objects (or even abstractions), then it’s possible to implement the pattern.

But why bother using this?

The Repository Pattern in WordPress

Photo by Samuel Zeller on Unsplash

In short, it provides an object-oriented way to pass information around your application without the need for global variables. Things such as dependency injection containers are also good for this, but they are beyond the scope of this post. I’d also argue that there are times in which they can be overkill in the context of small plugins.

Implementing the Pattern

With that said, how can we implement the registry pattern in WordPress and then leverage it throughout our work? Let’s take a look at the basic structure of the pattern, first:

Notice its implementation is quite simple:

  1. The class contains a single array as a private property.
  2. Data is added to the array with a specific ID.
  3. Data can be retrieved from the pattern with the ID.

You could even take this particular pattern to the next level if it accepts only a class of a certain type (like an AbstractEvent, for example) and then automatically invoke a function on the class whenever it’s passed in (or retrieved) from the registry.

But that’s getting into a more complex implementation that I’d like for this post.

Setting up the Registry

Because of the nature of WordPress’ hook system, there’s a particular way in which the Registry has to be setup and then registered with WordPress.

Let’s say you’re working with a plugin. Within the plugin’s bootstrap file, do something like this:

This creates the registry and then creates a corresponding filter that we can use later in the plugin to retrieve the registry and thus other objects that it maintains.

Using the Registry

To add an object to the registry, call the add function and pass a unique ID and an instance of the object. Note that our currently implementation will trash any previous instances of an object that has the same key and replace it with whatever we pass to it.

From there, you can then retrieve the objects that you’d stored in the registry:

And you can use them just as oyu would in any other way. But this avoids the use need for singletons, global variables, or other dangerous things.

A Word About Testability

Another advantage that I find with the implementation of this pattern is that it not only allows you to more easily write unit tests against it, but it also gives you the ability to write tests against the objects that it can hold.

By that, I mean you can write your classes more independent of WordPress thus separating the domain logic from the core application and making them more representative of the data they are supposed to maintain.