Why object-oriented programming is your next step as a WordPress developer

You’re a WordPress developer. You might have a few plugins under your belt or a theme or two. You build WordPress sites for clients or just for yourself. You’ve heard of object-oriented programming, but, each time you look into it, it makes no sense!

You tell yourself object-oriented programming isn’t useful or worth the trouble. The goal of this article is to focus on explaining this value to you. At the end of this article, you should have a clear understanding of why you should learn it.

Managing your expectation

Let’s get this out of the way. You won’t be an object-oriented programmer at the end of this article. One of the problems with teaching object-oriented programming is the expectation for immediate payoff. You wouldn’t read an article about the benefits of exercise, go running once and expect to be in shape. Same thing here.

You check the PHP documentation or an article on the subject. You put your functions in a class for your plugins. After all, that’s what the WordPress documentation tells you. Did you feel that made things better? Did you understand why you were doing that? Probably not.

The truth is that it’s not obvious. That’s why a lot of people struggle with it. Even if there are a lot of resources available. On top of that, a lot of people think they’re using object-oriented programming when, in fact, they’re not. This adds to the confusion on the subject. It also makes it a lot harder for you to understand the value of it.

Let’s start with what you know

If I asked you to explain to me how you program right now, could you do it? You write code every day, but you might not be thinking about how you’re writing that code. If you can’t explain what you’re doing, how can you understand what object-oriented programming is?

So let’s start by explaining the coding style you’re using right now.

Coding style, you say? Yes. Object-oriented programming is a coding style and not just about using classes in your code. This is the very misconception that cause so many issues for you and others.

You’re coding in procedural style

Procedural programming is one of the many programming styles in existence. It belongs to the larger family of structured programming. Object-oriented programming also belongs to it. This is why the two share many similarities.

Structured programming is all about organizing your code in a way that makes it stronger and easier to understand. Both procedural programming and object-oriented programming share that same goal. Object-oriented programming just does it better when used properly.

Let’s go back to procedural programming. The idea behind it is simple. You organize your code in a series of ordered steps. Those steps could be conditional by using if statements or a switch for example. That said, following those ordered steps is how you get your result.

This is how you solve your problems. This is critical to understand. When you write code to solve a problem, you write it as a series of specific steps. Those steps create your desired outcome or functionality.

This isn’t a bad way to program. Sometimes it’s the best solution for a problem. Themes are a place where procedural code makes a lot of sense. You’re going through specific steps rendering HTML.

Procedural programming in the wild

Let’s take a look at the following WordPress code. Your goal is to get a list of all the users who are authors registered after a specific date. You can see the steps taken to get that list.

get_users is a helper function around the WP_User_Query class. You could also just use the class to achieve the same outcome.

Both these examples use procedural programming. You achieve your desired outcome by using a set of ordered steps. WordPress is full of examples like these. That is because the WordPress APIs are there to hide the use of classes. It’s one of the strengths of WordPress, but it’s still procedural code.

Now, let’s take a look at this last example.

Wait this isn’t object-oriented programming? No, it’s not. Wrapping your code in a class doesn’t change how you solved the problem. You’re still going through the same steps to get your result.

Hitting your limits

Here is a common situation: you created a small plugin to solve a problem. Over time, your plugin grows more complex. Your users want more features, an admin page, options everywhere, etc.

You start experiencing growing pains. That’s because procedural programming has its limitations. Let’s talk about some of the problems you might run across.

Difficulty organizing your code

Some code, like your admin page(s), is easy to group together. Not all code is that way though. When you divide your code in steps, you might want to reuse a subset of it. You create a new function so that you can reuse it.

“Where do I put this function?”, you ask yourself.

You start by creating a separate PHP file to store them. When do you split that first file into smaller files? How do you name those files? There is an endless list of questions you might ask.

Structured programming makes you seek clarity in your code organization. If you only have functions with steps, it puts everything on the same footing. The distinctions between types of functions becomes arbitrary. This makes the organization of your code hard to manage.

If you work with a team, multiply that by 10.

Hard to reuse your code

Your code is nicely organized now. A client comes to you with a new project. You want to reuse some functionality from your plugin in that project.

How do you reuse dozens of functions acting together to solve a problem? You might just copy paste the code into the new project. Yet you now have that code in two places. Twice the bugs to fix and all that nasty stuff.

A common way to fix this is to create a plugin for that functionality. So you extract code from various files into a separate plugin, repeating the code organization exercise again.

You’re not done yet though. You need extra conditions for this new use case. As you add more logic, your steps get increasingly complex, harder to maintain. Your simple solution is no longer that simple.

Some problems are hard to break down in steps

It’s ok. You managed to break up your code into a plugin. You have functions with lots of conditions, but you have a solution. You use an $args array with defaults.

So now, your function is 100+ lines of code with dozens of conditions. Small changes have unintended consequences because the steps and conditions are complex.

“Boy is this complicated.”, you muse as you look at your function.

When there is a bug, you struggle to figure out what is going on. “What condition or group conditions caused the bug?”

As problems get more complex, you cannot break them down into steps like that. Well, you can do it, but it will bring you a lot of pain.

How object-oriented programming does things

As we said, you use procedural programming to solve problems using ordered steps. Object-oriented programming uses a class or classes working together to solve a problem. These solutions are called a software design patterns.

Another important element to object-oriented programming is the common features of those solutions. That said, these features deserves their own article to be explained properly. The example ahead will highlight some of them.

This brings us to the the usage of classes in object-oriented programming. It’s worth pointing out that their use is deceiving. Classes implement important features that define object-oriented programming, but they’re not mandatory. You can implement object-oriented solutions without ever using classes.

An example using the mediator pattern

The mediator pattern is an important software design pattern. You use it when you need a way for different classes to interact without being reliant of each other.

This reliance between classes is called coupling. Object-oriented programming is always striving to create less coupling between classes. The mediator pattern is one of the solutions to that problem.

The WordPress version

The mediator pattern is fundamental to WordPress. You might not be aware of it, but you use it all the time making plugins. It’s the hooks and filters system.

These are a small subset of the functions used by the hooks and filters system. They are, however, critical for understanding what object-oriented programming is about.

Why is this object-oriented programming

The first thing you might have noticed is that there are no objects used here. Even with no objects, this is still object-oriented programming. This goes back to those features mentioned earlier. The WordPress implementation has some of the features that an object-oriented solution should have.

It decouples plugin code from WordPress internal functions. The mantra “Don’t hack core” highlights the importance of decoupling. The hooks and filters system are the cornerstone of that idea.

The filter functions also maintains an internal list of the hooks using the $wp_filter global. An object-oriented solution always keeps internal information. This idea is part of a larger feature called encapsulation. Encapsulation helps keep your code modular and simple.

Weaknesses of the WordPress version

The critical weakness of the WordPress hook system is that it depends on a global variable. Your information is accessible to anyone who can tamper with it. It isn’t complete encapsulation.

The use of global variables limits the reuse of the code as well. You can copy-paste everything into another PHP project. That said, you can’t use the solution in a programming language that doesn’t use globals that way.

It’s not a universal solution to the problem.

What it could look like as a class

What if WordPress didn’t use globals to store hooks? What would a class implementing the hooks and filters look like?

The example is only the skeleton of the class itself. It means to highlight how a class can fix the vulnerabilities of the function version. Your hooks are now free of tampering because you store them internally in the object. That’s what the “protected” keyword does.

It’s also easy to reuse the class in your other projects. If you wanted your plugin to use its own separate hook system, you could do so. Although, there’s no reason to do it.

Object-oriented programming is about solving harder problems

While the example is simple, it has solved all the problems mentioned earlier. You managed to:

  • Organize your code around the problem you’re solving
  • Make your code easier to reuse
  • Solve a complex problem without writing messy code

And that’s really what it’s about. The reason why you should learn object-oriented programming. It’s not because it’s cool or everyone uses it.

It’s about them problems you’re trying to solve. Doing more complicated things without the headaches of using functions, moving ahead and not doing the same thing over and over again.

Notes: I’d like to give thanks to this article by Anthony Ferrara for some of my inspiration. It gives a brief, but enlightening overview of procedural vs object-oriented programming.

  • Peter Knight

    I was expecting a disappointing article raving about OO and poo-pooing procedural programming but actually this piece was great and transcended dogmatic tendencies. Nicely written.

    I think there’s this natural shift that happens along a WP dev’s growth to more OO principles, because mainly there’s a better recognition to use what approach when and the desire to have organized code as you tackle bigger projects gets stronger over time. I’m currently still struggling a bit with coupling between my classes though, but I’m getting there.

    • Thanks Peter! That’s the message I was hoping to get across.

      Object-oriented programming tends to be seen as sacrosanct once you learned it. It takes a lot of effort to take a larger view and see why you even made that transition in the first place.

      I hope to tackle coupling and many other subjects in the future. Maybe my article on the single responsibility principle can help you out?

  • Nice on Carl!

  • Dylan Ryan

    Wow. Such great examples! I’m loving everything I’ve read on here so far. I can’t wait to get a book!

  • It is hard to find concrete examples of the “whys” of OOP programming and your explanations were insightful. I find it much easier to decide the best route to code something with a list of reasons like you laid out. You were spot on about OOP being an approach to solving a problem rather than specific tools like classes. That paradigm shift isn’t elaborated on much and I think is the hardest aspect to learn.

    I really wanted to see how you would have rewritten the first procedural example from an OOP perspective. That is still a missing piece for me. I see where you went with the WP hooks example, but that is on a project scale completely different than the authors function you started out with. Lots of projects start out with ‘just extending’ something a bit like the authors function and I’m still at a loss to how to ‘start out on the right foot’ without feeling like I am over architecting it.

    Thanks for the great writing you are doing here!

    • I’m glad you found it insightful Josh! I’m sorry you were let down
      that I didn’t go back to the initial author example to show the OOP version.

      The initial author example was there to highlight the fact that wrapping the code into a class didn’t make it any more OOP. I think it’s important to realize that before you can look and find the answers you need. That’s what the purpose of that example was.

      Solving that problem in an OOP way would be more complex than the other example I used so I switched to that one.

      If you’re looking for a better OOP plugin example, I’d take a look at this article:


      OOP does lead to more architecting so it’s a bit of a rabbit hole in that aspect. I’m trying to advance cautiously at it.

      • Hey Carl, I wouldn’t say I was ‘let down’. Your main point about looking beyond wrapping things in classes in order to reap the benefits of OOP was on point.

        Thanks for the link to the single responsibility article. Those examples of how (and why) to separate code into different classes helped connect some of the dots for me.

        As far as architecting, this line of thinking seems to move towards a collection of plugin development helper classes as part of a regular workflow.

        Funny thing about rabbit holes…they are hard to advance into cautiously:)

  • Xedin Unknown

    WordPress, and most plugins, are what is called, “spaghetti with meatballs”, which is procedural code with bits of OO code thrown in for “good measure”. To me, this summarizes both the disadvantages of WP-style “OOP”, and the necessity of implementing solid, or even SOLID, principles. Great article. Thanks, Carl, for giving me something that is easily shareable instead of having to come up with the reasons all over again! 🙂

    • I’m glad you liked it! And yeah, the WP-style OOP does more arm than good in practice. It’s not understood that it’s really just a way to namespace code.