If you’ve done any work – or even any reading – on object-oriented programming, then you’ve likely come across the idea of immutability. That is the idea of something being unchanging.

Sometimes you can have immutable values, and sometimes you can have immutable objects (at least after they are instantiated).

Immutable Values in WordPress Plugins

The opposite of immutable (but he was my favorite ninja turtle, anyway).

The thing is, the more I work with object-oriented code, the less I tend to work with immutable variables. Sure, I’ll use constants as defined in a configuration file, but you’re not likely to find me storing values within a class as a const.

That probably implies something about me and my abilities, but it’s true. Thankfully, code reviews are great at helping you see opportunities on where to leverage strategies you normally wouldn’t. And such is the case with immutable values in WordPress plugins.

Of course, this is one of those things that was brought to my attention by a friend when reviewing my code.

Immutable Values in WordPress Plugins

When working with WordPress, many of us are likely familiar with functions.php and wp-config.php and the role they play in the core WordPress application.

Yes, there are times in which things belong in wp-config.php, and yes, there are times where things belong in functions.php, but sometimes I think that particular file is abused with far too many functions, values, and so on.

But what about plugins? Specifically, what about object-oriented plugins? Case in point, say you’re working with an API that requires an API key, so you don’t hit up against a particular rate limit with a free version of the application.

Usually, you might find me storing the value in the main plugin class as an instance variable that can be passed around, or maybe it’s in a container class to which I can refer and use its get method.

But what about using a const property in a class and then passing it around via setter injection?

For example, let’s say there is a plugin class that relies on a helper class to render something on the screen. The API key can be defined in this class and then passed into the helper when needed:

View the code on Gist.

Next, the helper class can make a call to the arbitrary API (I’m calling it Canvas since we’ll be hypothetically something) using its URL and passes the API key as part of the query string.

View the code on Gist.

This way:

  • there’s a single place in which the value is kept,
  • there’s a descriptive name indicating what it stores,
  • it can be passed to other classes with minimal dependency,
  • the other classes can refer to them as local variables or as instance variables (depending on how they are passed around).

Sure, there are other ways in which these values can be kept (again with using functions.php or something similar).

But if you’re working with object-oriented programming and you want to work with immutable values in a WordPress plugin, wouldn’t make sense to keep it in the context of the classes that make up the plugin?


Leave a Reply