在主题中使用OOP

#1 楼

根据您提供的示例，我可以理解您的困惑。这实际上是使用类的一种糟糕方法……并且仅仅因为使用了类，并不会使系统成为OOP。
对于Hybrid，他们只是在使用类来命名其函数的名称。考虑到Hybrid是一个主题框架，这样做是为了使子主题可以重用函数名称，而开发人员不必担心名称冲突。在许多情况下，主题框架（父主题）是如此复杂，许多子主题开发人员将永远无法确切了解幕后情况。
如果Hybrid不使用类结构，子主题开发人员将需要知道所有现有的函数调用是什么，以便避免重复使用名称。是的，您可以在所有函数的前面加上一个独特的代码，但这会使代码难以阅读，难以维护，并且如果您要开发更多希望使用相同功能的系统，则本质上是不可重用的。 br />回答您的问题

Wtf？这样做有什么意义？显然，您不会同时使用两个或多个相同主题的实例。

不，您不会使用两个或多个相同主题的实例。但是就像我说的，在这种情况下，将类结构视为对函数进行命名，而不是创建传统的对象实例。将所有内容集中在一起放在一个类中，然后将其实例化为调用方法（myClass->method();）或直接调用方法（myClass::method();），这是一种以可读，可重用的方式命名事物的非常干净的方法。
当然，您总可以使用类似而是使用myClass_method();，但是，如果要在另一个主题，插件或其他框架中重复使用任何此代码，则必须重新检查并更改所有前缀。将所有内容保持在课堂上会更加整洁，并使您可以更快地进行重新开发和重新部署。

假设插件为名称空间执行此操作（这很荒谬），但是主题借口是什么？我想念什么吗？

在大多数情况下，我都会同意你的看法。但是，大多数人正在迅速减少。我在MultiSite安装中托管了几个使用同一主题的变体的站点。与其一遍又一遍地重复创建相同的主题而没有微小的差异，我为父主题设置了一个“类”，所有子主题都扩展了该类。这使我可以为每个站点定义自定义功能，同时仍然保持整个网络的总体一致性。
一方面，主题开发人员可以选择基于类的方法来为其功能命名空间（这不是如果您在一个又一个地重复使用相同代码块的环境中工作，这是荒谬的。另一方面，主题开发人员可能会选择基于类的方法来方便子主题的扩展。

编写这样的主题有什么好处？

仅在您的网站上使用混合功能，对于最终用户而言，您几乎不了解优势。如果您要为Hybrid构建子主题，则命名空间和可扩展性将带来很多好处。如果您为ThemeHybrid工作，则优势在于可以在其他项目（Prototype，Leviathan等）中快速，高效地重用代码。
如果您是主题开发人员，并且喜欢Hybrid的特定功能，但不喜欢整个功能主题，优点在于可以在非混合项目中快速，高效地重用代码（假定它也是GPL）。

#2 楼

速度
我当前的基本主题有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扩展（请参阅问题3255）

Comment_Form->由{$theme_name}_Comment_Form扩展

#3 楼

要考虑的另一点是：速度。经过简短的查找/打印后，我发现〜1.700内部功能和〜1.400用户功能=〜3.100 / 3.200功能VS。约250个班级。我想这最能说明查找所需的内容。如果您在主题中要求约50-100个函数调用!function_exists('') ...，只需为一个定时器设置一个计时器，然后开始做一些数学运算即可。即使不是OOP，它也是使代码

1）可重用的
2）可维护的
3）可交换的
4）更快一些的好方法

当您查看网络中浮动的各种类以帮助您快速完成元框，小部件等时，那么最好使用提到的@toscho这样的控制器，因为您可以将类插入和插入并替换处理类的控制器中的某些行。

#4 楼

有人认为封装是OOP提供的唯一（或至少是主要的）好处，而继承和状态介于无聊与邪恶之间：

http://obiecte.blogspot.com/2008/ 09 / oop-sucks.html

作者谈论的更多是关于将类/对象用作结构而不是用作静态函数的容器，但有趣的是，从一个直率的人那里读到一个完全不同的问题在OOP营地之外。

我可以在Haskell中编写我的下一个WordPress插件。

#5 楼

噢，真是个讨论！我还必须承认，我经常使用类进行封装。这里的想法是，在我的插件中，我可以将函数包装在一个类中，并且在该类中使用非常简单，有意义的方法名称，这些名称即使在我编写的其他插件中也是通用的。在那种情况下，类是名称空间的替代品，我不得不在5.2.x环境中避免使用。

虽然很少有OOP对于模块化有用的实例，但是包装函数的简单动作也带来了跨插件可扩展性的额外好处。例如，我最近扩展了一个基于类的发票解决方案，这样我就可以扩展主类，向各种函数（带有parent :: calls）添加额外的代码，甚至替换函数，而所有这些都无需内部化扩展插件。

尽管如此，大多数情况下，类包装只是命名空间的替代品。

#6 楼

抱怨您未编写的代码有什么意义？

如果您不喜欢该代码，请自己编写！

简单。问题解决了。

程序员喜欢按照自己的方式做事。因此，不要以为您可以告诉他们如何编写代码，要喝哪种威士忌，要吸烟的香烟品牌或要遵循的宗教信仰。他们只是调试这种透析仪，并继续做他们想做的事情。 ;-)

代码不是诗歌。代码是Sinatra歌曲“ My Way”的变体...