php - 我应该将 superglobals 存储为包装类的属性还是应该直接访问它？

Question

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

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

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 是一个非常特殊的案例。但是你问是否有任何理由包装 super 全局变量。以下是一些可能的原因(不按顺序，也不完整):

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

2. 让代码更加灵活，因为您可以伪造请求和子请求来做一些有趣的事情，而这些事情在真正的全局状态下是不可能的。

   <

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

4. 对变量施加额外的约束。由于 $_SESSION 允许你在其内部设置任何你想要的东西，你可能会得到一个不可序列化的状态，这可能会给你带来问题。使用包装器，您有一个集中点，您可以在其中检查状态以确定它是否符合必要的约束条件。

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

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

7. 使类的依赖关系更容易理解。如果我给你一个使用 super 全局变量的类的 API，你无法判断该类是否访问了它，因此也无法判断该类究竟需要操作什么。但是如果你需要注入(inject)一个请求类，你可以快速地看一眼就知道这个类实际上确实需要请求中的一些东西来操作。从而提高可读性并进一步阐明您的 API。

现实中还有更多原因，但这些是我能想到的。