Function Documentation

WordPress Function Documentation Progress

Writing Plugins: Don’t Place All Methods in One Object

Objects should only contain a single purpose, but most plugins I’ve seen pack every method in a single object. This opposed to splitting the methods out into better logical objects which contain that purpose and allow reuse across multiple projects. I would like to instead propose a better way to write objects, which don’t violate the advantages and purpose of objects. Packing everything in the same object did cause problems prior to WordPress 2.3.

I believe the reason that plugin authors have for placing all of the methods in the same object is:

  1. To keep the plugin contained for the user.
  2. That it is easier to access all of the methods and properties.
  3. Place all data and methods in a single namespace.

Objects are supposed to solve the question of reuse. It should seem reasonable that if plugins were decoupled objects, then it would be possible to easily create that same plugin for another PHP application. That is probably not the intention of the plugin author, but it could be another user’s or mine.

A solution for plugins which do this, is to inherit the object and override the methods and data you need to change. I did this with a recent plugin, which allows me to upgrade the plugin’s code without having to make the same changes over and over again.

The general rule I keep is when I’m building a class is either to plan out what methods each one it going to have and what properties and finally how each will interact with the other. If you must jump in and code without planning then once you reached a point where you are adding methods and properties that fall outside the scope of the original functionality then stop and ask, “How can I refactor this?”

For me, it is a constant question I ask about my code, because unless you’ve been coding objects for most of your life, there can always be improvements made. Decoupling your code also has the advantage of allowing you to reuse, which is key with objects and functions, in another plugin or project.

Most plugins that I’ve seen are coupled and can not easily be refactored without an almost complete rewrite of the core systems. If this is the case, then good luck and I wish you the best for your plugin.

Better Standard

I personally don’t use classes for my plugins. However, if I were to use objects, I would do it in this matter.

I would have a single class for the activation, deactivation, and init hooks.

class MyPlugin_Core
{
    function activation_hook()
    {
        // Do activation stuff
    }

    function deactivation_hook() {  }

    function init_hook() {
        $objMyPlugin = new MyPlugin_DoesSomething();

        // Do stuff with MyPlugin_DoesSomething
    }
}

register_activation_hook( __FILE__, array('MyPlugin_Core', 'activation_hook') );
register_deactivation_hook( __FILE__, array('MyPlugin_Core', 'deactivation_hook') );

add_action( __FILE__, array('MyPlugin_Core', 'init_hook') );

More of how you should structure your plugins in a later post.

Updated: An object is an object and a singleton is an object which only returns one reference to itself. With objects, you can create any number, but the Singleton pattern restricts creation to only one. Thanks to Jamie Talbot for the correction!

Advertisements

January 16, 2008 - Posted by | Writing Plugins Series | , ,

5 Comments »

  1. Hi there!

    “The Singleton class pattern is, in a nutshell, storing all of your properties and methods in a single object (class).”

    Just a note that you probably shouldn’t use “Singleton” as that has an entirely different meaning in the world of patterns. Where you use it to mean a single class containing everything, in general use it means only allowing one instance of a class to be instantiated. A better word in your case might be “Monolithic”.

    And just as a counter argument, for WordPress programming I prefer to use classes for all plugins that are of substance, and then make a single global instance available (though ironically I don’t enforce that through the singleton pattern!). My reasons for this are varied, but the two biggest benefits are encapsulation of code and not clashing with other plugins’ method names.

    I agree that there’s not much use in putting template functions in a class (in fact, it makes them harder to use). But cse classes in a classical OO manner and you won’t have any problems.

    Cheers,

    Jamie

    Comment by Jamie Talbot | February 28, 2008 | Reply

  2. Or better yet, Monolithic Singleton.

    I’m not wrong in my use of Singleton, because that is just what they are, a single instance of a object. In my research, Singleton is the basic object structure. In my contemplation, I have evaluated that to mean that every object that functions independently of any other is a Singleton.

    Your definition means: Single Instance.

    Mine means: Single Purpose.

    You are however on to my lack of formal Class Pattern l33t ninja skillz, which I hope to buy a book or two to learn. Aside from the Singleton and probably Registry, there are very few other patterns, which I know the names of and have personally used.

    If you know of any good books (don’t have to be PHP) on object patterns, then I’ll accept suggestions. I have it down to two PHP books, I’m sure there are better ones out there. I think you can get most of the Gang of Four and the other one online, so I don’t really need those. Truthfully, I’m unsure how to apply the concepts of those books to PHP, but I’ve yet to read the entirely of the documents.

    Comment by Jacob Santos | February 28, 2008 | Reply

  3. Surely your definition means “Handles everything without delegating to other classes”? That would seem to be the opposite of “Single Purpose”… đŸ˜‰

    Anyhow, there’s only a couple there and it doesn’t look like they’ve been updated for a while, but http://www.patternsforphp.com has some useful ones, with supporting code.

    Cheers,

    Jamie.

    Comment by Jamie Talbot | March 18, 2008 | Reply

  4. Thanks, you bring up a good point. I’ll do some more research on this subject before I move the article/suggestion to the WordPress codex.

    Comment by Jacob Santos | March 18, 2008 | Reply

  5. @Jamie, you are correct (of course)! You already know that.

    I’m going to edit the post to reflect the correct information. Thanks for bring the correction to my attention.

    Comment by Jacob Santos | March 31, 2008 | Reply


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: