我想为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，既然包装器类无论如何都会被嘲笑，为什么要麻烦将超全局变量存储为类属性?这么多人这么做有什么特别的原因吗?我应该将超全局变量作为属性存储在它们的包装器中，而不是直接访问它吗?
Session是一个非常特殊的例子。但你问是否有必要包装超级全局变量。以下是一些可能的原因(不顺序，也不完整):
-
使代码更少依赖于全局状态，从而更容易测试。您可以测试依赖于全局状态的代码。但是它比被告知状态的测试代码更难也更脆弱。
-
使代码更灵活，因为你可以伪造请求和子请求来做一些有趣的事情，这在真正的全局状态下是不可能的。
-
使代码更易于移植。通过将其包装在包装器中，您可以在中心位置处理与平台相关的事情，例如去掉引号、处理字符集转换等。这可以更容易地处理平台之间或多个平台之间的转换。
-
对变量强制附加约束。因为$_SESSION允许你在它内部设置任何你想要的东西，你可能会得到一个不可序列化的状态，这可能会给你带来问题。有了包装器，您就有了一个可以检查状态的集中点，以确定它是否与必要的约束相匹配。
-
使你的代码更易读。当然，几乎每个php开发人员都知道在方法中访问$_POST是在做什么。但是他们需要知道实现细节吗?还是说
$request->getFromPostData('foo');更啰嗦? -
使你的代码更容易调试，因为你可以在请求类中设置一个断点，并立即发现访问请求变量的所有事件(只要你从不直接访问它们)。
-
使你的类的依赖关系更容易理解。如果我给你一个使用超全局变量的类的API，你无法判断这个类是否访问了它，因此也无法判断这个类需要操作什么。但是如果您需要注入一个请求类，那么您可以一眼看出这个类实际上确实需要请求中的某些东西来操作。
现实中有更多的原因，但这些是我能想到的。
我不认为有什么重要的原因，也许只是如果你改变了之后引用的超全局变量，你不必在类的整个代码中替换它，而只需在构造函数中替换它。
从这个角度来看，我发现你提供的第一个实现的write方法不是很明智，它既写类属性又写会话变量，正如你所说的。