正确包含 PHP 中的设计实践 [关闭]

Posted 2023-02-24

【中文标题】正确包含 PHP 中的设计实践 [关闭]

【英文标题】：Proper include design practice in PHP [closed]

【发布时间】：2014-11-30 19:39:00

【问题描述】：

我刚刚开始研究一个更大的预先存在的代码库 (php)，我注意到很多这些文件以不可读的方式使用包含/要求。文件系统中的includes/requires 是一种级联，因为系统中的几乎每个文件都包含/requires 一个名为common.php 的文件。这个公用文件包含/需要几乎所有其他文件，所以当开发人员有疑问时，他们似乎只是包含/需要公用文件并称之为好。

这是由专业的 Web 开发人员编写的，我还是个学生，所以我很好奇这是否是 PHP 中的常见做法。在 PHP 中是否应该有一个包含/需要所有内容的通用文件，是否应该逐个包含/需要每个文件，或者是否有不同的常见做法？

附带说明：我正在尝试将 api 文件切换为新文件（同时保留旧文件以进行兼容性测试），我很难判断哪些文件使用我的新 api 或旧文件.

【问题讨论】：

不，将每个包含都放在一个文件中并不常见。

这更多的是根据具体情况，但是您可能想在此处评估 include 和 require 之间的区别：***.com/questions/3633900/…

至少，如果太乱的话，最好使用 _once 版本：php.net/manual/en/function.include-once.php（还有 require_once）

一种常见的做法确实是使用不好的方法，就像你描述的那样。许多自称为专业开发人员的人都这样做。你所描述的是一种不好的方法。正确的方法是在需要时加载包含，也称为“延迟加载”。这就是为什么 php.net 的酷人给了我们自动加载器的原因。更有意识和现代（真正的专业）开发人员使用它。他们走得更远，使用称为 Composer 的依赖管理器工具来管理依赖和自动加载，使整个加载过程变得艰难，包括和不属于过去的事情。

是的，这是令人沮丧的普遍现象，尤其是在较旧的代码库中，不，这不是好的做法。好的做法是使用模块化 OOP 代码和自动加载器：php.net/manual/en/function.spl-autoload-register.php。然而，遗留代码就是这样。

【参考方案1】：

一般来说，includes 应该用于基于视图的材料（html、Smarty，也许是 XML 或 XSLT），就像在 MVC approach 中构建视图的标记一样。但是，require(); 或 require_once(); 用于控制在功能或面向对象设置（MVC 中的控制器和模型）中合并服务器端核心功能。

require(); 或 require_once(); 都提供了一种编程安全机制，如果代码失败，代码将停止运行并将错误发送到日志 - 请参阅 require 和 require_once 的文档。尽管出现错误，include(); 仍将继续运行错误代码 - 你不希望这样。

对于您关于“包含所有内容”的文件的另一个问题，一些 PHP 框架（如 Zend 和 CodeIgniter）允许称为自动加载器的东西 - 这会加载所有可用的类并实例化主要的核心类供程序员使用随意的对象。

如果您不使用框架，您可以通过创建配置或在您的情况下创建一个通用文件来模拟这一点。但是，您可能不想随意加载所有内容，因为这可能会在其他开发人员稍后尝试排除故障时造成混乱 - 正如您现在可能会发现的那样。您将不得不评估、测试和重新构建您的代码，以确定哪些是真正常见的，哪些在您的代码中很少使用。我过去通过跟踪来做到这一点 - 添加error_log() 和var_dump() 以便在数据通过代码时跟踪数据。

【讨论】：

对不起，我在使用 require 和 include 时可以互换使用。我了解两者之间的区别，我对系统的整体包含结构更加好奇。我已经编辑了我的问题。

@TheBat 我已经进行了编辑，希望能更全面地解决您的问题；)

谢谢，这一切都清楚了。我只是想弄清楚我是否应该建议管理重构，但我想我会处理它哈哈。感谢您提供有关调试包含级联的提示，我只需要弄清楚它的代码。

【参考方案2】：

当您掌握 PHP 的窍门时，可能是熟悉 PSR 的好时机。您可以在PHP-FIG 网站上找到各种 PSR 标准的定义。您还将找到许多关于该主题的精彩教程（我会让 google 处理相关链接）。

具体到您的问题是 PSR-0 和 PSR-4，每个都处理自动加载。关于自动加载和 PSR 的争论仍在继续，并不是每个人都有好感。不管你喜不喜欢，这是一个会更频繁地遇到的现实，能够理解和利用它会极大地提高你前进的舒适度。

遵循 PSR 确实使您的代码更易于组织外部人员阅读，并且可以更轻松地通过 composer/packagist 公开共享您的项目。