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