反对global变量的重点是它们非常紧密地耦合代码。您的 整个代码库 取决于a）变量 名称
$config和b）该变量的存在。如果要重命名变量（无论出于何种原因），则必须 在 整个代码库中的 任何地方
进行重命名。您也不能再使用任何依赖于变量的代码了。

带有global变量的示例：

require 'SomeClass.php';

$class = new SomeClass;
$class->doSomething();

在上述各行中的任何地方，您都可能会出错，因为类或某些代码SomeClass.php隐式依赖于全局变量$config。尽管只看了课，却没有任何迹象表明。要解决此问题，您必须执行以下操作：

$config = array(...);

require 'SomeClass.php';

$class = new SomeClass;
$class->doSomething();

如果未在其中设置正确的键，则此代码可能 仍会
失败$config。由于不清楚配置数组的哪些部分SomeClass需要或不需要以及何时需要它们，因此很难为其创建正确的环境以使其正常运行。如果您碰巧已经有一个变量$config要用在其他任何地方，它也会产生冲突SomeClass。

因此，不要创建隐式，不可见的依赖关系，而是 注入 所有依赖关系：

require 'SomeClass.php';

$arbitraryConfigVariableName = array(...);

$class = new SomeClass($arbitraryConfigVariableName);
$class->doSomething();

通过显式传递config数组作为参数，可以解决上述所有问题。这就像在应用程序内部 分发所需的信息
一样简单。它还使应用程序的结构和流程以及讨论的内容变得更加清晰。要达到这种状态（如果您的应用程序当前是一个大问题），可能需要进行一些重组。

您的代码库越大，则您越需要 将 各个部分彼此 分离
。如果每个部分都依赖于代码库中的每个其他部分，则您根本无法单独测试，使用或重用它的任何部分。那简直变成混乱。为了将各个部分彼此分开，请将它们编码为类或函数，这些类或函数将其所有必需数据作为参数。这就在代码的不同部分之间创建了清晰的接缝（接口）。

尝试将您的问题归纳为一个示例：

require_once 'Database.php';
require_once 'ConfigManager.php';
require_once 'Log.php';
require_once 'Foo.php';

// establishes a database connection
$db = new Database('localhost', 'user', 'pass');

// loads the configuration from the database,
// the dependency on the database is explicit without `global`
$configManager = new ConfigManager;
$config = $configManager->loadConfigurationFromDatabase($db);

// creates a new logger which logs to the database,
// note that it reuses the same $db as earlier
$log = new Log($db);

// creates a new Foo instance with explicit configuration passed,
// which was loaded from the database (or anywhere else) earlier
$foo = new Foo($config);

// executes the conversion function, which has access to the configuration
// passed at instantiation time, and also the logger which we created earlier
$foo->conversion('foo', array('bar', 'baz'), $log);

我将把各个类的实现留给读者练习。当您尝试实现它们时，您会注意到它们非常容易实现且清晰明了，不需要一个即可global。每个函数和类都以函数参数的形式传递其所有必要的数据。还应该显而易见的是，上述组件可以以任何其他组合的形式插入在一起，或者可以轻松地替换其他组件。例如，配置完全不需要来自数据库，或者记录器可以登录到文件而不是数据库，而Foo::conversion无需了解任何信息。

示例实现ConfigManager：

class ConfigManager {

    public function loadConfigurationFromDatabase(Database $db) {
        $result = $db->query('SELECT ...');

        $config = array();
        while ($row = $result->fetchRow()) {
            $config[$row['name']] = $row['value'];
        }

        return $config;
    }

}

这是一段非常简单的代码，甚至没有做很多事情。您可能会问为什么要将此作为面向对象的代码。关键是，这使该代码的使用极为灵活，因为它可以将其与其他所有代码完美地隔离开来。输入一个数据库连接，返回一个具有特定语法的数组。输入→输出。清晰的接缝，清晰的界面，最少的，明确定义的职责。您可以使用简单的功能执行相同的操作。

对象具有的额外优点是，它甚至可以进一步将调用的代码loadConfigurationFromDatabase与该函数的任何特定实现分离。如果仅使用global
function loadConfigurationFromDatabase()，则基本上还会遇到相同的问题：尝试调用该函数时需要定义该函数，如果要用其他函数替换它，则存在命名冲突。通过使用对象，代码的关键部分移至此处：

$config = $configManager->loadConfigurationFromDatabase($db);

您可以$configManager在这里替换同样具有method的
任何其他对象loadConfigurationFromDatabase。那就是“鸭子打字”。$configManager只要它有一个方法，您都不关心它到底是什么loadConfigurationFromDatabase。如果它走路像鸭子，而嘎嘎叫鸭子，那它就是鸭子。或者说，如果它有一个loadConfigurationFromDatabase方法并返回有效的配置数组，则它是某种ConfigManager。您已将代码与一个特定变量$config，一个特定loadConfigurationFromDatabase函数甚至一个特定变量解耦ConfigManager。可以从任何地方动态更改和替换所有零件，并进行替换和加载，因为代码不依赖于任何其他特定零件。

该loadConfigurationFromDatabase方法本身也不依赖于任何一个特定的数据库连接，只要它可以调用query它并获取结果即可。该$db对象被传递到它可能是完全伪造的，并从XML文件中读取其数据或其他地方代替，只要它的
界面 仍然表现相同。