开发插件时，是否应将函数分组到一个类中以避免名称空间冲突？
是的，但这只是一个小论点。事实上，这不是OOAD.
使用类是否会给PHP带来性能开销？
不，不明显。糟糕的设计和/或糟糕的编写代码或过早的优化会比实际的语言功能产生更多的性能问题。
如果性能受到影响，是否应该预先修复函数名？
如前所述，没有性能影响。写得不好的代码比写得好的代码会对性能造成更大的影响，写得好的代码会有更多的代码行，但不会强迫你做坏事。
<小时>
Bottom Line:
您可以为插件使用不同的类。您可以使用它们来创建某种名称空间，并将它们“仅仅”用于全局函数。最直接的形式是静态类函数，下面的代码示例显示了这两种函数，首先是全局函数，然后是全局静态类函数：
/* global function */
function myplug_hook()
{
}
add_filter(\'the_hook\', \'myplug_hook\');
/* global static function */
class myplug
{
public static function hook()
{
}
}
add_filter(\'the_hook\', \'myplug::hook\');
这只是一个小示例，说明您需要为单个挂钩键入更多内容。此外，它还显示了名称空间的工作原理：您可以更轻松地替换单个类名，以重命名所有静态函数，然后搜索和替换
myplug:: 这可能会更难
myplug_ 因为误报。但最终差别不大。
关键是：static class functions Docs 那就没什么别的了global functionsDocs.
这个示例也显示了：名称空间很好，但对于WorpPress，名称空间停止使用挂钩：回调函数是硬编码的，因此当您使用wordpress对挂钩名称进行干预时，使用类（基名的一个位置，类名）的名称空间的好处没有帮助。
真正的好处始于使用实际的类实例和非静态函数。这样做的好处是，您可以开始使用OO原则，并且可以简化代码。静态类函数与其说是一个解决方案，不如说是一个问题。
那就不仅仅是句法上的糖分了。
关键点是：做一些可以帮助您编写易于处理和维护的代码的事情。不要过分评价性能，这是一个常见的错误。更重要的是，您编写的代码很容易阅读和理解，可以满足您的需要。也许这个问题和答案有助于从更大的角度来看这一问题：Multiple Custom Metabox Help.
对于较小的插件，我有一种常见的方法，即使用静态助手函数实例化插件，其余的则驻留在插件实例中。这有助于封装主插件逻辑，并受益于使用挂钩的名称空间，以及可以在挂钩之间重用私有成员，这在标准全局函数中是不可能的。以下代码示例显示了该模式：
<?php
/** Plugin Headers ... */
return MyPlugin::bootstrap();
class MyPlugin
{
/** @var MyPlugin */
static $instance;
static public function bootstrap() {
if (NULL === self::$instance) {
self::$instance = new __CLASS__;
}
return self::$instance;
}
# ...
}
这是我用于基本插件文件的常见模式。plugin类一方面表示wordpress的插件，另一方面它允许开始为自己的代码使用面向对象的范例，这些代码甚至可以完全面向对象（但不需要）。它是一种控制器，作为请求与整个wordpress API接口。
如示例所示，将创建插件的一个实例。这允许您使用已知的公共资源，如Constructor Docs (__construct) 要初始化实际插件，请执行以下操作：
# ...
class MyPlugin
{
# ...
public function __construct()
{
add_filter(\'the_hook\', array($this, \'hook\'));
}
public function hook()
{
}
# ...
}
在钩子注册时，这个插件对象已经从它的设计中获益：您已经停止对具体插件的实际钩子函数进行硬编码。这是可能的，因为类绑定到回调的对象实例。听起来很复杂，只是说：
$this 是插件。可用于钩子回调，比较Registering Class methods as hook callbacks.这种模式允许更容易地与wordpress进行接口：注入被简化为挂钩的名称以及它们提供的数据。然后，您可以开始直接实现到这个插件类中，或者根据它重构您的实现，以便只将代码放在插件类中，这是根据wordpress定义插件接口的最低要求，但不要使用wordpress的一般逻辑。这就是乐趣的开始，也很可能是每个插件作者想要实现的长期目标。
因此，不要使用worpdress编程，而要反对它。由于worpdress非常灵活，因此没有通用或易于描述的接口可供编程使用。一个基本插件类可以扮演这个角色，使您能够更灵活地编写自己的代码，从而使代码更简单，性能更好。
因此，名称间距不仅仅有好处。我能给你的最好建议是：试试你自己。你不会失去太多，只会发现新的东西。
在通过wordpress的一些主要更新后，您很可能会注意到不同之处，同时保持插件的兼容性。
警告：如果您的插件直接与wordpress集成以完成任务，那么使用一个或两个公共功能可能更适合您。使用适合工作的工具。
