我应该将超全局变量存储为包装类吗？属性还是我应该直接访问它？

Question

我想为 Session 和 Request 创建一个包装器，这样我就不必直接访问 PHP 超全局变量。我意识到，如果我为超全局创建一个包装器并使用它们，对我的应用程序进行单元测试将会更容易，因为包装器类可以被模拟。

在尝试创建我的包装类时，我研究了一些示例包装类。其中一些在初始化时将超全局存储为类属性：

class Session
{
    protected $vars;

    public function __construct()
    {
        session_start();

        // POINT OF INTEREST
        // Store the superglobal as a class property
        $this->vars = $_SESSION;
    }    

    public function get($index)
    {
        // POINT OF INTEREST
        // Accesses the class property instead of the superglobal
        return $this->vars[$index];
    }

    public function write($index, $value)
    {
        // Writes both class property and session variable
        $this->vars[$index] = $value;
        $_SESSION[$index] = $value;
    }
}

我的问题：为什么在创建包装类时我们将超全局存储为类的属性而不是直接访问它们，是否有任何特殊原因？将上面的代码与下面的代码进行对比：

class Session
{
    public function __construct()
    {
        session_start();
    }

    public function get($index)
    {
        // Accesses the superglobal directly
        return $_SESSION[$index];
    }

    public function write($index, $value)
    {
        // Accesses the superglobal directly
        $_SESSION[$index] = $value;
    }
}

IMO，既然包装类无论如何都会被模拟，为什么还要费力将超全局变量存储为类属性呢？这么多人这样做有什么特殊原因吗？我应该将超全局变量作为属性存储在其包装器中，而不是直接访问它吗？

感谢您的任何意见。

Answer 1

Session 是一个非常具体的案例。但你问是否有任何理由包装超级全局变量。以下是一些可能的原因（不按顺序排列，也不完整）：

1. 为了使代码更少依赖于全局状态，从而更容易测试。您可以测试依赖于全局状态的代码。但它比测试被告知其状态的代码更困难、更脆弱。

2. 为了使代码更加灵活，因为您可以伪造请求和子请求来完成真正的全局状态不可能完成的有趣的事情。

3. 使代码更加可移植。通过将其包装在包装器中，您可以在中心位置处理依赖于平台的事情，例如剥离引号、处理字符集转换等。这可以更轻松地处理平台之间或多个平台之间的转换。

4. 对变量实施附加约束。由于 $_SESSION 允许您在其内部设置任何您想要的内容，因此您可能会遇到不可序列化的状态，这可能会导致问题。使用包装器，您可以拥有一个集中点，您可以在其中检查状态以确定它是否符合必要的约束。

5. 使您的代码更具可读性。当然，如果您在方法中访问 $_POST，几乎每个 PHP 开发人员都知道您在做什么。但他们需要了解实施细节吗？还是 $request->getFromPostData('foo'); 更冗长？

6. 为了使您的代码更易于调试，因为您可以在请求类中设置断点并立即找到所有访问请求变量的情况（只要您从未直接访问它们）。

7. 使类的依赖关系更容易理解。如果我为您提供了一个使用超级全局变量的类的 API，您将无法判断该类是否访问了它，因此也无法判断该类需要操作什么。但是，如果您需要注入一个请求类，那么您一眼就能看出该类实际上确实需要请求中的某些内容才能进行操作。因此，可以提高可读性并进一步阐明 API。

现实中的原因还有很多，但我暂时能想到的就这些了。

Answer 2

我不认为有一些重要原因，也许只是如果您之后更改了您所指的超全局，则不必在类的整个代码，但仅在构造函数中。

从这个角度来看，我发现您提供的第一个实现的 write 方法不太明智，正如您所说，该方法同时写入类属性和会话变量。

然而，所有这些似乎有点矫枉过正（并且想得太多）。保持简单并做对你有用的事情。