我看到很多插件在没有必要的时候使用面向对象的编码。
但更糟糕的是，主题开发人员也开始做同样的事情。商业主题和自由流行的主题，如Suffusion，甚至我最喜欢的主题-Hybrid，将它们的所有函数都塞进一个类中，在函数中实例化一次。php并以过程方式运行其函数：）
世界跆拳道联盟？这样做有什么意义？显然，您不会同时使用同一主题的两个或多个实例。
让我们假设插件是为名称空间这样做的（这很荒谬），但是主题的借口是什么呢？我错过了什么？
编写这样的主题有什么好处？
Using OOP in themes
6 个回复
最合适的回答,由SO网友:EAMann 整理而成
根据你提供的例子，我可以理解你的困惑。这真是一个糟糕的使用类的方法。。。而且，仅仅因为使用了类，就不会产生系统OOP。
在混合的情况下，它们只是使用一个类来命名其函数的名称空间。考虑到Hybrid是一个主题框架，这样子主题就可以重用函数名，而无需开发人员担心名称冲突。在许多情况下，主题框架（父主题）是如此复杂，许多子主题开发人员永远无法确切了解引擎罩下的情况。
如果Hybrid没有使用类结构，则子主题开发人员需要知道所有现有函数调用是什么，以便避免重复使用名称。是的，您可以在所有函数前面加上一个唯一的slug，但如果您开发更多希望使用相同功能的系统，那么代码就很难读取、维护，并且固有的不可重用性。
回答您的问题？这样做有什么意义？显然，您不会同时使用同一主题的两个或多个实例。
不，您不会使用同一主题的两个或多个实例。但正如我所说，在这种情况下，将类结构视为函数的名称空间，而不是创建传统的对象实例。将所有内容集中到一个类中，或者实例化它以调用方法(myClass->method();) 或直接调用方法(myClass::method();) 是一种以可读、可重用的方式命名事物的非常干净的方法。
当然你可以用这样的东西myClass_method(); 相反，如果您想在另一个主题、插件或其他框架中重用这些代码，您必须返回并更改所有前缀。将所有内容保持在一个类中更干净，并允许您更快地重新开发和重新部署。
让我们假设插件是为名称空间这样做的（这很荒谬），但是主题的借口是什么呢？我错过什么了吗？
在大多数情况下，我都同意你的看法。然而，这一多数正在迅速减少。我在多站点安装上托管了几个使用相同主题变体的站点。与其一次又一次地重复相同的主题，只留下一些细微的差异，我有一个；“类别”；对于父主题和所有子主题，扩展该类。这使我能够为每个站点定义自定义功能，同时仍然保持整个网络的一致性。
一方面，主题开发人员可能会选择一种基于类的方法来命名其功能（如果您在一个反复使用相同代码块的环境中工作，这并不荒谬）。另一方面，主题开发人员可以选择基于类的方法，以便于通过子主题进行扩展。
编写这样的主题有什么好处？
如果你只在网站上使用Hybrid，那么作为最终用户，你几乎没有什么优势可言。如果您正在为Hybrid构建子主题，那么名称空间和可扩展性会带来好处。如果你为ThemeHybrid, 其优势在于跨其他项目（Prototype、Leviathan等）快速、高效地重用代码。
如果您是一个喜欢混合的特定特性而不是整个主题的主题开发人员，那么其优势在于在非混合项目中快速、高效地重用代码（假设它也是GPL）。
SO网友:fuxia
速度
我当前的基本主题有13个类。当我构建一个新主题时，我要么按原样使用这些类，要么扩展它们。这个系统使得构建新主题的过程非常、非常快。紧凑的作用域
我很少需要全局变量，因为我的代码必须知道的一切都隐藏在类成员中。因此，我能够在两个非常不同的过滤器或操作之间共享一个变量，而不会与编写糟糕的插件发生冲突。维护每个类是一个文件。如果我需要更新客户端的主题，我只需要更新一些文件。只要我提供相同的API，类内部发生的任何事情都由我决定。
示例：在comment_form(); 调用时，我使用一个简单的操作：
do_action( \'load_comment_class\' );
comment_form();
用纯粹的程序方法来尝试这一点，你会发疯的。：）
可读性
如果您将所有内容按任务分开，那么几个月后重新阅读和理解您自己的代码就容易多了。一些有用的类层次结构示例Meta_Box ->；扩展人Shortdesc_Meta_Box 和Simple_Checkbox_Meta_Box ->；扩展人Sidebar_Switch
User_Profile_Addon ->；扩展人User_Profile_Checkbox （参见Question 3255)Comment_Form ->；扩展人{$theme_name}_Comment_FormSO网友:kaiser
要考虑的另一点是：速度。
if ( !class_exists(\'cccYourClassName\') )
// VERSUS
if ( !function_exists(\'ccc_your_function_name\') )
!function_exists(\'\') 在你的主题中大约有50-100个功能。。。只需设置一个计时器，然后开始计算。即使不是OOP，这也是编写代码的好方法1） 可重用
2）可维护
3）可交换
4）速度稍快
当您看到web上浮动的不同类可以帮助您快速完成元框、小部件等操作时，最好使用上面提到的@toscho这样的控制器，因为您可以将类插入和插入，并替换控制器中处理类的一些行。
SO网友:tex
有人认为封装是OOP提供的唯一（或至少主要）好处，继承和状态介于无聊和邪恶之间：
http://obiecte.blogspot.com/2008/09/oop-sucks.html
作者谈论的更多的是将类/对象用作结构，而不是静态函数的容器，但有趣的是，对于这个问题，阅读一个完全不同于OOP阵营之外的人的观点。我可能会在Haskell中编写下一个WordPress插件。
SO网友:Jester831
哦，讨论得真好！我还必须承认，我使用类进行封装的频率远远高于不使用类。这里的想法是，在我的插件中，我可以将我的函数封装在一个类中，并在该类中使用非常简单、有意义的方法名，即使在我编写的其他插件中也是通用的。在这种情况下，类是名称空间的替代品，我不得不在5.2中避免使用名称空间。x环境。
虽然OOP对模块化有用的实例很少，但简单地包装函数也会带来跨插件可扩展性的额外好处。例如，我最近扩展了一个基于类的开票解决方案，因此我可以扩展主类，为各种函数添加额外代码（w/parent：：calls），甚至替换函数，所有这些都不需要内部化扩展插件。
尽管如此，类包装在很大程度上只是名称空间的替代品。
SO网友:Mark
抱怨你没有写的代码有什么意义？
如果你不喜欢这个代码，就自己写吧！
易于理解的问题已解决。
程序员喜欢按自己的方式做事。所以，不要以为你可以告诉他们如何编写代码，喝什么样的威士忌，抽什么牌子的香烟，或者信仰什么。他们只会对这种诽谤进行调试，然后继续做他们想做的事
代码不是诗歌。代码是西纳特拉歌曲“我的方式”的变体。。。
结束