Advice on plugin structure

Question

I'm looking for a bit of advice on structuring the classes within a plugin I'm writing for my charity website.

At the moment the plugin is OOP based with a single class. However, its becoming quite ungainly with a lot of functions in a single file. I'm wondering if it would be better to split out separate aspects into different classes, so for example one class for front end, one for back end and one for when validating options.

The difficulty I get into is the best way to call each class and how to handle helper functions. My initial thinking was to have a 'parent' class which would then 'require' the appropriate class depending on a number of checks (such as is_admin). My difficulty is what to do with the helper methods and variables. If I put them in the parent class, how would I access them in the child class?

Any thoughts would be appreciated.

Answer 1

You should limit your helper functions. In a rather big plugin I am writing currently (~50 classes) I have just three helper functions, placed in the plugin main file:

/**
 * Delete plugin option on deactivation.
 *
 * @return boolean
 */
function t5_delete_option() {
    return delete_site_option( 'plugin_t5' );
}


/**
 * Load a class from /inc/ directory.
 *
 * @since  2012.10.26
 * @param  string  $class         Class name
 * @param  boolean $create_object Return an object or nothing
 * @return bool|$class
 */
function t5_load_class( $class, $create_object = FALSE ) {

    $path = plugin_dir_path( __FILE__ ) . "inc/class-$class.php";

    if ( ! file_exists( $path ) )
        return FALSE;

    class_exists( $class ) || require_once $path;

    if ( $create_object )
        return new $class;

    return TRUE;
}

if ( ! function_exists( 'pre_print' ) ) {

    /**
     * Print debug output
     *
     * @since  2012.11.03
     * @param  mixed
     * @return void
     */
    function pre_print( $var, $before = '' ) {

        $export = var_export( $var, TRUE );
        $escape = htmlspecialchars( $export, ENT_QUOTES, 'utf-8', FALSE );
        print "$before<pre>$escape</pre>";
    }
}

All other classes are placed in a directory /inc/ (not my choice, I have to work within existing rules for that).

The file structure should reflect what the files are for, not where they are used, because that can change any time.

Implement a main controller class that loads the files you need in your current situation. So have to look at one place only to see what is going on.

The main controller collect some data (plugin URL, current user’s IP address, an instance of the custom database class …) and passes these data as a property list object to the called classes. So there is never a need for global access to anything besides the class loader (I don’t use an autoloader) and the tiny debug function.