当前位置: 首页>>建站开发>>正文


在主题中使用OOP

webfans 建站开发 , , , 去评论

问题描述

在没有必要时,我看到很多插件都使用了object-oriented编码。

但更糟糕的是,主题开发人员开始做同样的事情。商业主题和免费流行主题,如Suffusion,甚至我最喜欢的主题 – 混合,将所有功能填入类中,在functions.php中实例化一次,并以程序方式运行其功能:)

跆拳道?这样做有什么意义?显然,您不会同时使用同一主题的两个或更多个实例。

让我们假设插件为命名空间执行此操作(这很荒谬),但主题借口是什么?我错过了什么吗?

编码这样的主题有什么好处?

最佳解决思路

根据您提供的示例,我可以理解您的困惑。这真的是一种使用类的糟糕方式……并且仅仅因为使用了一个类,所以不会使系统成为OOP。

在Hybrid的情况下,他们只是使用一个类来命名它们的功能。考虑到Hybrid是一个主题框架,这样做是为了让子主题可以在没有开发人员担心名称冲突的情况下使用re-use函数名。在许多情况下,主题框架(父主题)是如此复杂,许多儿童主题开发人员永远不会完全理解底层的内容。

如果Hybrid没有使用类结构,那么子主题开发人员需要知道所有现有的函数调用是什么,以便他们可以避免使用re-using名称。是的,您可以使用一个独特的slug为您的所有函数添加前缀,但这会使代码难以阅读,难以维护,并且如果您需要开发其他想要使用相同功能的系统,则本质上non-reusable。

回答你的问题

Wtf? What’s the point of doing this? Obviously you won’t be using two or more instances of the same theme, at the same time.

不,您不会使用同一主题的两个或更多个实例。但就像我说的那样,在这种情况下将类结构视为命名空间函数,而不是创建传统的对象实例。将所有内容集中在一个类中并将其实例化为调用方法(myClass->method();)或直接调用方法(myClass::method();)是一种以可读,可重用的方式命名事物的非常简洁的方法。

当然你总是可以使用像myClass_method();这样的东西,但如果你想在另一个主题,plug-in或者其他框架中使用re-use这些代码,你必须返回并更改所有前缀。保持课堂上的一切都更清晰,让您可以更快地重新开发和重新部署。

Let’s assume that the plugins do this for the namespace (which is ridiculous), but what’s the theme excuse? Am I missing something?

在大多数情况下,我同意你的看法。然而,大多数人正在迅速减弱。我在MultiSite安装上托管了几个使用相同主题变体的网站。而不是re-create相同的主题一遍又一遍地有微小的差异,我有一个”class”用于父主题,所有的子主题都扩展了该类。这允许我为每个站点定义自定义功能,同时仍然保持整个网络的一致意义。

一方面,主题开发人员可以选择class-based方法来命名他们的功能(如果您在re-use块中反复使用相同代码的环境中工作,这并不荒谬)。另一方面,主题开发人员可以选择class-based方法,以便通过子主题轻松扩展。

What’s the advantage of coding a theme like this?

如果您只是在您的网站上使用Hybrid,那么作为最终用户,您几乎没有什么优势。如果您正在为Hybrid构建子主题,则命名空间和可扩展性具有优势。如果您在ThemeHybrid工作,那么优势在于在您的其他项目(Prototype,Leviathan等)中快速,高效地重用代码。

如果您是主题开发人员喜欢Hybrid的特定功能而不是整个主题,那么优势在于您的non-Hybrid项目中快速,高效的代码重用(假设它也是GPL)。

次佳解决思路

Speed

我目前的基础主题有13个班级。当我构建一个新主题时,我要么按原样使用这些类,要么扩展它们。该系统使得构建新主题的过程非常非常快速。

范围很窄

我很少需要全局变量,因为我的代码必须知道的所有内容都隐藏在类成员中。所以我能够在两个非常不同的过滤器或动作之间共享一个变量,而不会有与写得不好的插件冲突的风险。

Maintenance

每个类都是一个文件。如果我需要更新客户端的主题,我只需更新一些文件。只要我提供相同的API,在课程中发生的任何事情都取决于我。

例如:在comment_form();调用之上,我使用一个简单的操作:

do_action( 'load_comment_class' );
comment_form();

将加载哪个注释类决定我的控制器。注释类中确实发生了什么决定了个别类。

尝试使用纯粹的程序方法,你会疯了。 🙂

Readability

如果你把任务分开了几个月,那么几个月后重读和理解你自己的代码要容易得多。

有用的类层次结构的一些示例

  • Meta_Box – >通过Shortdesc_Meta_BoxSimple_Checkbox_Meta_Box延伸 – >由Sidebar_Switch扩展

  • User_Profile_Addon – >由User_Profile_Checkbox扩展(见Question 3255)

  • Comment_Form – >由{$theme_name}_Comment_Form扩展

第三种解决思路

另一点需要考虑:速度。

if ( !class_exists('cccYourClassName') )  
// VERSUS  
if ( !function_exists('ccc_your_function_name') )

经过短暂的查看/打印后我发现~1.700内部功能和~1.400用户功能= ~3.100 /3.200功能VS. 〜250级。我想这最能说明需要多少查看。如果你在主题中约50-100个函数调用!function_exists('') …只需设置一个计时器,然后开始做一些数学运算。即使它不是OOP,它也是制作代码的好方法

1)可重复使用2)可维护3)可交换4)更快

当你看看网上浮动的不同类,它们可以帮助你快速地进行元框,小部件等操作时,最好使用像@toscho这样的控制器,因为你只需要插入类,然后只需要替换它们控制器中处理类的一些行。

第四种思路

有人认为封装是OOP提供的唯一(或至少是主要的)好处,而继承和状态介于无聊和邪恶之间:

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

作者更多地讨论了将类/对象用作结构而不是静态函数的容器,但是对于那些完全不同于OOP阵营之外的人来说,阅读完全不同的问题是很有意思的。

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

第五种思路

哦,相当讨论!我不得不承认,我经常使用类进行封装。这个想法在我的插件中,我可以将我的函数包装在一个类中,并且在该类中使用非常简单,有意义的方法名称,即使在我编写的其他插件中也是如此。在该实例中,类是命名空间的替代,我不得不在5.2.x环境中避免使用。

虽然很少有OOP对模块化有用的例子,但是包装函数的简单行为也会增加cross-plugin可扩展性。例如,我最近扩展了一个基于类的发票解决方案,这样我就可以扩展主类,为各种函数添加额外的代码(w /parent :: calls)甚至替换函数,所有这些都不需要内化扩展插件。

但是,Allas的大部分包装只是命名空间的替代品。

参考资料

本文由朵颐IT整理自网络, 文章地址: https://duoyit.com/article/2364.html,转载请务必附带本地址声明。