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

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 WordPress Plugin with Multiple Classes

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 is one of those things that is actually easier to do from the start of a project rather than refactoring an existing project.

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?

30 Comments

Tom,

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?

    ::shameless plug::

    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.

    Over time, I plan to cover some of this in future posts though I don’t have a particular schedule as to when I’ll actually get to it.

    I do have some resources that are available, though:

    I contributed to a series here on Envato.
    I have two boilerplates – one for plugins and one for widgets
    I have several plugins available on GitHub all of which use the object-oriented approach.

    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:

    Classes
    Constructors
    Attributes
    Public, Private, and Protected keywords

    Those four things will help immensely when writing object-oriented plugins.

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. :)

    Yeah, it takes time if you’re not coming from that background. I say the same thing about functional programming since my background is in OOP :).

    That said, be sure to review this comment for a few pointers. Hopefully they’ll help :).

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.

    When I face this particular challenge, I always try to explain what each class does.

    If I have trouble doing that or each class is doing more than one thing, then I usually take that as a sign that the class needs to be split up into separate classes.

    Just a rule of thumb, though.

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.

    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.

    Yep – you’re right. I’m guilty of this, too but it’s a habit I’m working to break primarily because I feel like it’s taking the easy way out.

    It’s kind of “just because it can be done doesn’t mean it should be done.” I say that because it inevitable results in technical debt when you have to continue to develop and maintain the plugin.

    honestly just using callbacks can be more flexible than the methods / inheritance model as well.

    Absolutely – in the proper use case, I think you bring up a really smart point. Props for that. I’ve not often considered this in the case of several of my plugins.

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 :)

    I agree with you. Unless you’re writing a more complex plugin, the majority of the higher-order OOP features won’t necessarily be used.

    In the cases that a developer does bump up against them, it’ll be a good opportunity for learning and yet-another-thing to add to their OOP toolbox :).

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.

    Thanks Ian, clearly I’m a fan of it :).

    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).

“lan” I have seen your slides which help me very much for applying them on plugins.Thanks for shaing knowledge about object oriented wordpress plugin.

Hi Ian,

What approach would you advocate about using the settings API in the plugins? May a bit of code added to the Broilerplate code would be helpful

Cheers
Tarique

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. :)

    Props on making a plugin – that’s awesome!

    I’d say don’t worry about going OOP just for the sake of going OOP – make sure that the reasons you’re doing it are around.

    Will it help clean up the code?
    Will it help with maintenance
    Is it going to help make the code more readable?

    And so on.

    Just food for thought :).

Hi! I really like this blog. Tell me please – from where do you have information for ths blog?

Sascha Turowski May 7, 2013 at 4:37 pm

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.

Hi,

This article is really helpful, thanks for sharing. I am looking forward to read more articles in future. Keep writing!!! cheers.

Trackbacks and Pingbacks

[...] blog to keep myself updated and learn new things about plugin development. This week he wrote an interesting article about object oriented plugin development, something which I plan to start implementing myself. Its an excellent introductory post and I hope [...]

[...] McFarlin takes a look at why and how to make your WordPress plugins [...]

[...] Object Oriented Plugin Development [...]

[...] McFarlin takes a look at why and how to make your WordPress plugins [...]

Leave a Reply

Name and email address are required. Your email address will not be published.

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>