为什么我应该停止在 PHP 中使用全局变量并拥抱依赖注入？

停止在 PHP 中使用全局：拥抱依赖注入

不鼓励在 PHP 中使用全局变量，因为它可能会创建紧密耦合的代码，阻碍灵活性，并引入安全风险。本文深入探讨了为什么应该避免 global，重点是一个具体的例子，并提供了一种基于依赖注入的更高效的解决方案。

全局变量的问题

全局变量的首要问题是它们隐含的本质。通过将变量声明为全局变量，可以在整个代码库中创建对它的直接依赖关系。对变量名称或可用性的任何更改都会立即影响应用程序的其他部分。这种隐式依赖关系可能会导致混乱，尤其是在较大的代码库中，从而使跟踪错误和维护代码变得更加困难。

注入依赖关系

管理跨不同部分共享的变量的更好方法代码库是依赖注入。这涉及将所需的依赖项作为参数显式传递给函数或类，而不是依赖于全局可用的变量。通过这样做，依赖关系变得明确且易于管理。

现实示例

为了说明全局变量的问题，请考虑一个假设的场景，其中配置数组 $config 存储在config.php 文件并包含在应用程序的多个页面中。在特定的函数 conversion() 中，全局 $config 声明成为访问配置数据所必需的。

function conversion($Exec, $Param = array(), $Log = '') {
    global $config;
    $cmd = $config['phppath'] . ' ' . $config['base_path'] . '/' . $Exec;
    foreach ($Param as $s)
    {
        $cmd .= ' ' . $s;
    }
}

通过拥抱依赖注入，我们可以将 $config 数组直接传递给 conversion() 函数，如下所示一个参数，消除了对全局变量的需要。

function conversion($Exec, $Param = array(), $Log = '', $config) {
    $cmd = $config['phppath'] . ' ' . $config['base_path'] . '/' . $Exec;
    foreach ($Param as $s)
    {
        $cmd .= ' ' . $s;
    }
}

现在， conversion() 函数变得更加模块化，并且更少依赖于全局变量。它可以在应用程序的其他部分使用，无需包含 config.php 文件或全局 $config 声明。

扩展示例：使用数据库连接

场景可以进一步扩展以演示数据库连接的依赖注入。假设我们有一个 Database 类和一个方法 loadConfigurationFromDatabase()，它从数据库中获取配置数据。

class Database {
    // ...
    public function loadConfigurationFromDatabase() {
        // ...
        return $config;
    }
}

要使用依赖注入访问配置数据，我们可以将 Database 类的实例传递给函数或类，并调用 loadConfigurationFromDatabase() 获取配置数组。

// ...
$db = new Database();
$config = $db->loadConfigurationFromDatabase();
// ...

这种方法干净地分离了数据库连接以及从应用程序代码的其余部分加载配置的过程，使其更易于维护和测试。

依赖注入：通往更简洁代码的途径

总之，虽然全局变量看起来很方便，但它们引入了隐式依赖并限制了代码的灵活性。通过采用依赖注入，开发人员可以促进解耦代码、增强模块化并提高整体软件质量。走上这条道路会带来更清晰、更可维护和可扩展的代码库。

以上是为什么我应该停止在 PHP 中使用全局变量并拥抱依赖注入？的详细内容。更多信息请关注PHP中文网其他相关文章！