Object-Oriented WordPress Plugin Development

When it comes to writing plugins – specifically those that are object-oriented in nature – many of us do so because we’re obviously fans of writing object-oriented code.

Personally, I’m a fan of it because it helps to separate the responsibilities and concerns of a requirement into its own logical unit.

Sure, this can be done with several function files as well, but I come from an object-oriented background, so when I approach a problem, I automatically begin thinking in terms of classes and their relationship to one another.

And I know that other developers do the same.

The thing is, I think some of us – myself included – have gotten lazy or we only half-bake our object-oriented-based plugins. That is to say that we may be using classes in writing our plugins, but we don’t do such a good job of taking advantage of other object-oriented principles and features.

An Object-Oriented WordPress Plugin, But Not Really

Here’s the thing: It’s relatively common to see a class-based plugin and then assume it’s object-oriented. But simply using a single class does not truly make it object-oriented.

Instead, I’d say that you’re using an object-oriented feature, but you’re not truly object-oriented programming.

For example, a lot of plugins will use a single class to do their work. A high-level diagram would look something like this:

The god-class of a WordPress Plugin

Basically, you have the follow setup for your plugin:

The class name

Any private attributes that may be used throughout the class

The constructor were hooks and other initialization code is setup

Then a huge area dedicated to functions

This isn’t necessarily bad, but if you’re aiming for truly object-oriented code, there’s likely a need for refactoring.

If you have a single class that’s doing all of the work, then it likely has multiple responsibilities which decreases its identity. Quite simply, you have a god-class – or a god-object – and this is an antipattern.

It’s easy to get away with doing this. Look at a lot of my source code, and you’ll see that I’m doing this same thing. I hate it, but I rationalize doing it because it’s faster and the plugin is free (I’m careful not to do this in commissioned plugins, but that’s a topic for another post).

Have Some Class: Break Up Your Work!

Punny, right?

Anyway, in true object-oriented programming, a given class would have a single-purpose and the attributes and methods would be related to that single purpose.

This means that what once was a god-class would be broken up into smaller, more logical units of code. Yes, this creates more classes, but more classes isn’t necessarily a bad thing.

A more cohesive plugins

In this example, you have three classes each with its own set of attributes, initialize code, and functions. Additionally, each class serves a single purpose and not all of them are aware of one another.

In fact:

There’s a core plugin file that would ideally be instantiated when the plugin is called

It has a reference to a Mailer class which is responsible for mail operations

And it has a Manager class which could be responsible for, say, creating, updated, and removing users from the system that are created by the plugin

On top of the that, the main plain class has a reference to each of the other classes, but the Mailer isn’t aware of the Manager. Why should it be? In this case, the core plugin class needs only to send data to and from each class.

Ultimately, this makes for more highly specialized, focused code. It gives each class a stronger level of identity, and it makes maintenance a heck of a lot easier.

Rewrite All The Code! (Or Not)

This isn’t to say that it can’t be done, but the amount of time required and the amount of testing required to make sure that nothing is broken could be far more substantial that you – or a team – is willing to invest.

Regardless of what route you choose, I think there’s room for improvement in how we’re all writing our object-oriented plugins. Again, I’m guilty of this just as much as the next person so I’m writing more to myself than anyone else.

But it’s nice to get it out in the open so I at least know I’ll be held accountable if I release something that doesn’t actually practice what I’m preaching, you know?

Related

30 Comments

Great post. I’ve fallen into this trap as well but I’m not sure how to dig my way out because I don’t have a lot of experience in this arena. Do you plan on writing any tutorials on how to properly structure such a beast? If not, where do coders who want to “do it the right way” go to learn about proper class structure?

I gave a presentation last month to the Seattle WordPress Developer’s Meetup about how to integrate the MVC pattern and OOP paradigm into WP plugin development. We didn’t get a video, but you can check out the slides if you’re interested.

It goes into the basic theory of each, and then gives some practical tips on how to apply them to plugins. There’s also a ton of links at the end to tutorials, articles, etc.

I’ve also written a starter plugin that tries to implement all the basic principles, so reading through that code might help you see an example of how to break things up, and other principles you can apply.

Granted, this isn’t the same as a tutorial, but hopefully they’ll provide a bit of a starting point.

I’ll say this: For simpler plugins, complex object-oriented concepts aren’t necessarily needed. If you’re interested, in the meantime, in researching some stuff on your own then I’d recommend familiarizing yourself with the follow concepts:

This is totally how I want to develop plugins – it seems much more elegant to me. But not coming from an OOP background, it’s taking some time to get my head wrapped around it. So I appreciate that you’re continuing to laud the OOP methodology. It’ll sink in eventually. :)

Great and timely post! I am experimenting with my first OOP plugin right now. The decision on how to split your classes is a tough one especially if you have alot of cross over. Now I have a huge Utils class to handle crossovers.

I’ve done this, refactored a plugin to use OOP; what I ended up with is basically an abstract “God class” that I now use as a starting point / framework for building other modules and plugins. I’ll note that it’s pretty common in WordPress development to just use the class as a namespacing tool, even to the point of not instantiating it, using only static variables / methods, etc. For plugins, often you want the main plugin class to be a singleton anyhow, and for attaching to hooks, if you use the class name, then you don’t have to pass around / keep track of a global instance. That’s not the path I took, but honestly just using callbacks can be more flexible than the methods / inheritance model as well.

Don’t worry about your lack of experience in real OOP-driven languages. The life cycle of an application in say Java, C#, C++ or Python is entirely different, OOP has a real and complete and apparent application there. PHP based OOP is very limited due to the fact that a web application reloads every single request and persisting data or messaging components is obsolete as it comes as an overhead more than an elegant solution.

It doesn’t mean that you should not write OOP-based plugins, but many of the use cases won’t take advantage of 4/5 of the OOP principles :)

Great article. I’m glad to see more people in the WP community preaching the OOP gospel :)

I started out just writing “object-oriented functions”, but that was a good stepping stone to get me into the actual theory and principles of OOP design. I still just wrap everything in a single class with smaller functionality plugins, but I’ve found that creating a starter plugin that already has a lot of the design established makes it much easier to stick to good design in new projects.

For instance, I create an abstract class for a generic module, and then have all the other classes extend it, and then use interfaces for custom post types and other repeatable entities. So, when I create a new class, I’m literally forced to conform to the structure of the abstract class or interface, at least on a superficial level.

I think that your approach is starting with “object-oriented functions” then moving up to true OOP is the path a lot of developers end of taking if for nothing else than keeping code more cohesive.

As far as your abstract class is concerned, doing that or creating an interface class is really smart not only because it forces your actual implementations to conform to a particular design, but because it makes it really easy to create classes for use in unit testing (should you ever opt to go that route).

In some cases, it may make more sense to attach settings to the individual classes, and just have a central settings class provide more of a framework to make it easier for the individual classes, but it depends on the size of the project and how deep you want to get into OOP design.

Nice post..!
I have made a plugin for wordpress last month, however since it was my first plugin and a pretty simple one as well I have just used a bunch of functions only. However I think I should really go on with OOP concept and release a v2 now. :)

Hi,
Great article!
I started to write a Newsletter-Plugin that fits the requirements of a customer. I started by using the procedual approach.
After a few lines of code i switched to the OOP-approach very fast. Here are the reasons why:
The Plugin has to handle different tasks. Handling Bounced Mails, Subscribing and Unsubscribing, Tracking and Management of Subscribers.
I decided to go the “Test-Driven-Development”-Way. Using some Designpatterns and OOP-Concepts like SOLID, helps me a lot to organise my codebase and writing testable code.
The best of all! Because of using TDD I’m not scared about possible necessary refactorings in future.
I think using OOP -the right way- leads to a higher codequality, especially in larger WP-Plugins.

When you have as many conceptual objects like’ve mentioned (Bounced Mails, Subscribing and Unsubscribing, Tracking and Management of Subscribers, etc), using OOP makes a lot of sense.

I don’t think that it’s the end-all-be-all of way to develop plugins – I’ve done some that are simply procedural – however, I prefer to use OOP as much as possible for the reasons that you’ve mentioned.

I’ve seen lots of plugins implementing god-like classes and have always struggled to understand why this is done when most OOP theory advocates a far more modular approach to creating classes. Why, in your opinion, do developers continue to define god-like classes which include everything but the kitchen sink? I mean, are there any advantages to having god classes?

I think that’s usually a sign that the developer has just started to get into OOP, and has learned the syntax of the paradigm, but not the design principals. Over time they’ll learn more about the design side, and start modeling their classes after the domain space.

Alternately, they may just want a way to get a namespace so they don’t have to prefix all their function names to avoid collisions. (The new namespaces construct wasn’t added to PHP until 5.3, so many devs might not be familiar with it yet, or they might want to support 5.2.x until WordPress drops it.)

Thanks for replying. Wanting to avoid function naming collisions sounds likely but I think I would rather use a prefix than sacrifice good practice. I’ve seen plugins define a single class which, aside from the methods you’d expect in a well-written class, has multiple vaguely-related methods such as: load the plugin’s text domain, enqueue styles and scripts, perform activation tasks, deactivation tasks, uninstall tasks etc. Often, I see this kind of approach used with the singleton pattern, so multiple instances of the class can’t be created. I’ve seen this kind of plugin setup so often, even from experienced developers. Is this an acceptable approach or am I right to question it?