Plugin class organization, best practice

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

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?

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

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 ??

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.

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.