php - 在 PHP 中实例化类或使用静态方法

Question

我正在学习 OOP，并且正在创建一个 WordPress 插件。我浏览了一堆不同的流行 WordPress 插件，它们都使用不同的编码风格和方法来实现相同的功能。

我创建了以下精简函数作为示例。一些插件将使用一种样式，而其他插件将使用其他样式。

功能是简单地在 WordPress 帖子编辑屏幕中打印出 3 个按钮。什么被认为是解决此问题的正确/首选/最佳方法？

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;
}

像上面那样实例化 3 个不同的类？

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;

}

使用静态方法打印上面的按钮？

function sliced_print_buttons( $id ) {

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

}

或者创建单独的函数来打印按钮？

在查看所有不同的 WordPress 插件和阅读 OOP 时，我感到很困惑。非常感谢一些指导。

Answer 1

第一种编码实践会带来什么问题？

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.

来自 Rethinking object oriented wordpress plugins