在 PHP 插件中包含第三方库时避免类名冲突的模式？

Question

我正在编写一个 WordPress 插件。 （但是，这不是 WordPress 特定的问题 - 这个挑战可能出现在 任何 使用插件模式的 PHP 代码库中。）

我的插件使用了一个流行的第三方库，许多其他常见的 WordPress 插件也使用了该库。

显然，如果我的插件和另一个插件都加载了他们自己的这个库的副本，PHP 会抛出一个错误，因为我正在尝试重新声明一个已经声明的类。

如何避免这种冲突？在您回答之前，请考虑一下我为什么拒绝这些显而易见的选项：

• 我可以重命名库的类，或者将它们放在新的命名空间中。我不喜欢这样，因为它涉及修改库文件。如果我以后需要升级到更新版本的库，它会覆盖我的修改。而且它通常只是一个不雅的 PITA。

• 在我的插件真正包含库之前，我可以使用class_exists() 来确保它尚未被包含。我不包含的原因有两个喜欢这个选项：

  • 另一个插件可能使用不同版本的库，其 API 略有不同。这可能会导致我的插件或 other 插件中断（取决于首先加载的库版本）。
  • 更重要的是：该库包含多个类定义文件，每个子类都包含其父类。假设我的插件包含 ChildClass1.php（它又包含 BaseClass.php），而 another 插件包含 ChildClass2.php（其中 也 包含它自己的 BaseClass 副本.php）。 class_exists() 在这里对我没有帮助 - 两个插件都无法在不引起冲突的情况下包含他们需要的 ChildClass。

那么：我怎样才能在不遇到这些问题的情况下使用这个库呢？有没有办法在包含时覆盖库的命名空间（不修改库）？还有其他一些我忽略的解决方案吗？看来这一定是很常见的情况。

Answer 1

我正在回答我自己的问题。 （我不敢相信三年前我还这么天真！）

这个问题（以及其他问题）正是依赖管理器存在的原因。 （如果你使用 npm，那么你已经熟悉依赖管理了。）

在 PHP 世界中，Composer 是依赖管理的标准工具。

然而，WordPress 并不是真正为与依赖管理器（或源代码控制）配合而构建的。事实上，WordPress 积极地反对这些做法。

有一个名为 Bedrock 的项目，它试图将 WordPress 扭曲为与现代开发实践兼容的东西。我没用过——但如果您必须使用 WordPress，那么值得研究一下。

tl;博士：

• 解决此问题的方法是使用依赖管理器，例如 Composer。
• 但是，WordPress 与 Composer 根本不兼容——它会在每一步都与您抗争，而且您会制造比您解决的问题更多的问题。
• 除非您使用 Bedrock 的 WordPress 版本 - 旨在与 Composer 配合使用。
• 但是，在这一点上，您不妨放弃 WordPress，并采用一个设计合理的 CMS 平台，而 不必为了与行业合作而被扭曲和折磨- 标准做法。