Title: Plugin class organization, best practice
Last modified: August 21, 2016

---

# Plugin class organization, best practice

 *  [noplanman](https://wordpress.org/support/users/noplanman/)
 * (@noplanman)
 * [12 years, 8 months ago](https://wordpress.org/support/topic/plugin-class-organization-best-practice/)
 * Hi all!
 * I’m busy writing a new plugin and have reached a stage where I’d like to know
   what the best practice for class organization is. More specifically, I’d like
   to find out what the best way of linking classes together is.
 * At the moment I have the following classes/components that need to be linked 
   together wisely:
    MyPlugin (singleton) MyPlugin_Options (singleton) MyPlugin_Shortcode
   MyPlugin_Widget
 * Which ones should extend which ones? And which ones should be singletons or not
   or what.
 * The way I thought it would make sense:
    MyPlugin (singleton) MyPlugin_Options(
   singleton) MyPlugin_Shortcode MyPlugin_Widget extends MyPlugin_Shortcode
 * For the widget class, it should be extending WP_Widget, but obviously I can’t
   extend both at the same time.
    So how should I organize my classes to have them
   all linked together nicely?
 * Hope it’s clear what I mean…
 * Thanks for your help!

Viewing 6 replies - 1 through 6 (of 6 total)

 *  [catacaustic](https://wordpress.org/support/users/catacaustic/)
 * (@catacaustic)
 * [12 years, 8 months ago](https://wordpress.org/support/topic/plugin-class-organization-best-practice/#post-4184737)
 * Classes should be organised logically. That’s really the only rule for it. You’d
   want to start off by looking for classes that have similar functionality and 
   can be grouped together, and those are the ones that should be extended/inherited
   from. Others that don’t share any sort of common ground should be their own stand-
   alone classes.
 * Your main classes can be singletons, but they don’t need to be – that part is
   dependant on how you set up your methods. If everything is `static` then you 
   can make then singletons, but if not they’re better off being normal classes 
   that you’d instantiate. Personally, I haven’t used singletons for those sort 
   of classes because in my cases it didn’t make sense.
 * I’m not sure that you’d want to extend a shortcode class for widgets. Shortcodes
   and widgets are different things, so there’s no logicla connection between the
   two and there’s no reason to extend one from the other. You’d be better off having
   a base widget class and extending that to create your widgets (but there’s already
   the standard WP_Widget class for that).
 *  Thread Starter [noplanman](https://wordpress.org/support/users/noplanman/)
 * (@noplanman)
 * [12 years, 8 months ago](https://wordpress.org/support/topic/plugin-class-organization-best-practice/#post-4184769)
 * Thanks for your reply.
 * The reason why I would extend the Widget class with the Shortcode class is that
   the widget I had planned would basically be a text field to input a shortcode!
 * What would make the most sense then? Have the shortcode class with a static method
   that does the shortcode work?
 *  [catacaustic](https://wordpress.org/support/users/catacaustic/)
 * (@catacaustic)
 * [12 years, 8 months ago](https://wordpress.org/support/topic/plugin-class-organization-best-practice/#post-4184770)
 * OK, that makes a little more sense, but still… you’re not using that class as
   an actual shortcode, so it’s “more correct” to be a widget class and jsut use`
   do_shortcode()` as it needs to rather then inheriting from a shortcode class.
 * The shortcode doesn’t have to be static. I never do it that way, but it’s up 
   to you how you want it to work. For me the basic object for shortcodes would 
   be something like this:
 *     ```
       class My_Shortcode {
   
           public function __construct(  ){
               add_shortcode( 'my_shortcode', array( $this, 'shortcode' );
           }
   
           public function shortcode(  ){
               // Prepare output here
   
               return $html.
           }
   
       }
   
       $my_shortcode = new MyShortcode()
       ```
   
 *  Thread Starter [noplanman](https://wordpress.org/support/users/noplanman/)
 * (@noplanman)
 * [12 years, 8 months ago](https://wordpress.org/support/topic/plugin-class-organization-best-practice/#post-4184771)
 * What I’ve done now, that seems to work fine, is that instead of having all singleton
   classes, just my main one and the options are. Reason for the options being singleton
   is simply that I don’t have multiple objects around with potentially different
   option values inside them. Within the main class i have private objects with 
   instances of the shortcode and widget (My widget class extends WP_Widget). In
   the widget __construct() i then get the shortcode object from the main class,
   which i then use to make my shortcode output.
 * Is this nice?! What would be nicer?
 * My goal is to make it as “clean” and manageable as possible 🙂
 *  [catacaustic](https://wordpress.org/support/users/catacaustic/)
 * (@catacaustic)
 * [12 years, 8 months ago](https://wordpress.org/support/topic/plugin-class-organization-best-practice/#post-4184773)
 * I believe that you’re over-thinking this.
 * The main goal of OO is to make the code easier for you (and anyone looking at
   it after you) to read and maintain. if what you’re doing does that for you, then
   it’s fine. As I said right back at the start, there’s no real rules for what 
   is and isn’t acceptable. It varies on a case-by-case basis every time.
 * Are there other ways to do it? Yes.
 * Are there better ways to do it? Maybe.
 * Should you do it another way? Only if how you’re doing it now doesn’t work for
   you.
 *  Thread Starter [noplanman](https://wordpress.org/support/users/noplanman/)
 * (@noplanman)
 * [12 years, 8 months ago](https://wordpress.org/support/topic/plugin-class-organization-best-practice/#post-4184774)
 * Ok, over-thinking could be the situation…
 * Thing is, I’m planning to have a clean, organized code which can easily be read
   and understood by any 3rd party. Additionally, my plugin will have elements that
   can be built by anyone and added easily. Hence, the whole way the objects talk
   to each other needs to be clear and logical.
 * Thanks for your help, I’ll try to make it as sensible and logical as possible
   as far as I can.

Viewing 6 replies - 1 through 6 (of 6 total)

The topic ‘Plugin class organization, best practice’ is closed to new replies.

## Tags

 * [classes](https://wordpress.org/support/topic-tag/classes/)
 * [organize](https://wordpress.org/support/topic-tag/organize/)
 * [Practice](https://wordpress.org/support/topic-tag/practice/)

 * In: [Hacks](https://wordpress.org/support/forum/plugins-and-hacks/hacks/)
 * 6 replies
 * 2 participants
 * Last reply from: [noplanman](https://wordpress.org/support/users/noplanman/)
 * Last activity: [12 years, 8 months ago](https://wordpress.org/support/topic/plugin-class-organization-best-practice/#post-4184774)
 * Status: not resolved

## Topics

### Topics with no replies

### Non-support topics

### Resolved topics

### Unresolved topics

### All topics