Instantiating a class or using a static method in PHP

2 Views

I am learning OOP and I am creating a WordPress plugin. I’ve looked through a bunch of different popular WordPress plugins and they all use different coding styles and methods to achieve the same things.

I have created the below stripped down functions as an example. Some plugins will use one style, whereas other plugins will use the others.

Read More

The function is to simply print out 3 buttons within a WordPress post edit screen. What would be considered the correct/preferred/best way to go about this? 

function sliced_print_buttons( $id ) {

    $emails = new Sliced_Emails();
    $pdf = new Sliced_Pdf();
    $admin = new Sliced_Admin();

    $email_button = $emails->get_email_button( $id );
    $pdf_button = $pdf->get_pdf_button( $id );
    $convert_button = $admin->get_convert_invoice_button( $id );

    echo $email_button;
    echo $print_button;
    echo $convert_button;
}

Instantiate 3 different classes as above? 

function sliced_print_buttons( $id ) {

    $email_button = Sliced_Emails::get_email_button( $id );
    $pdf_button = Sliced_Pdf::get_pdf_button( $id );
    $convert_button = Sliced_Admin::get_convert_invoice_button( $id );

    echo $email_button;
    echo $print_button;
    echo $convert_button;

}

Use static methods to to print the buttons as above? 

function sliced_print_buttons( $id ) {

    echo email_button();
    echo print_button();
    echo convert_button();

}

Or create separate functions that could print the buttons?

I’m getting myself pretty confused looking through all of the different WordPress plugins and reading up on OOP. Some guidance would be much appreciated.

Post Views: 2

Related posts

1 comment

  1. What problems come from the 1st style of coding practice?

    Lack of coherency. The class is basically being used as a plugin namespace. It’s laudable to try to avoid polluting the global namespace with all your function names, but using a consistent, unique prefix for your functions accomplishes the same thing. Instead you end up with data and methods that look like they’re related to each other, but really have the most tenuous connection of being part of the same plugin.

    Poorly implemented singletons. Every plugin class really needs to be a singleton. Having two instance of the class would cause a range or problems, from inefficiency (e.g., running the same query multiple times) to possible conflicts as the first instance of the plugin filters some data that is then re-filtered by the second instance. I’m not saying that singletons are inherently bad, but they are definitely overused (Wikipedia says so!, and, to quote the “Bible”, “Be suspicious of classes of which there is only one instance”), and when they are used, they should be used deliberately and with proper care taken to avoid multiple instances.

    Barriers to code reuse and abstraction. Classes created this way can’t really be sub-classed (although I’ve yet to see a final keyword in front of a class), partially because of the singleton problem mentioned above, partially because there’s no clear definition of what the class is, so it doesn’t make sense to make a more specific version of it. This gets in the way of creating abstractions to share common code among similar classes, and greatly increases the complexity of any plugin of reasonable size.

    From Rethinking object oriented wordpress plugins

Comments are closed.