Question

我正在阅读关于对象健美操的内容，其中一条规则是wrapping primitive types and strings：

class UIComponent {

    public function repaint($animate = true)
    {
     // 
    }

}

$component->animate(false);

变为：

class UIComponent {

    public function repaint(Animate $animate)
    {
     //
    }
}

class Animate {

    private $animate;

    public function __construct($animate = true) 
    {
        $this->animate = $animate;
    }
}

$component->animate(new Animate(false));

这项技术有什么好处？在我看来，我认为这只是复杂的事情，并添加了更多的代码。

Answer 1

在这种情况下，它确实有点超大，但还有其他例子，它可以有意义

class Identifier {
  protected $id;
  public function __construct ($id) { 
    if (!preg_match('~^{a-z0-9]$~i', $id)) throw new Exception("Invalid id '$id'");
    $this->id = $id;
  }
  public function getId () { return $this->getId(); }
}

所以这个是不可变的，它确保了特定的格式。当你在另一个类中对这个类进行类型提示时，你不需要测试，无论标识符是否有效

class MyClass {
  protected $id;
  public function __construct (Identifier $id) { $this->id = $id; }
}

这只是一个简单的例子，事实上它在php中并不常见。

[..]并添加了更多行代码。

我不认为“更多代码行”本身就是坏事。如果它需要更多行（甚至类），编写可读和干净的代码，它比紧凑但不可读的东西好得多。

Answer 2

想象一下，在第一个例子中读取代码的新开发人员（或者您可能在您上次触摸项目一年后）：

$component->repaint(false);

如果不跳到repaint()的定义或以其他方式阅读方法的文档，您绝对无法知道false在方法行为方面的含义。我的意思是，它实际上是读取＆＃34;重绘虚假＆＃34;，所以...重新绘制但是......实际上并没有重新绘制？ intent 不清楚，这是件坏事。

这个非常简单的示例用于演示如何通过包装基元来大大提高代码可读性。当你想在简单的验证中添加一些像烘焙这样的行为并将自己与另一个实例进行比较时，这些好处甚至更大。

对于新的这样一个小小的物体对性能的影响，你根本不应该担心。至于＆＃34;更多代码行＆＃34;为什么那么糟糕？ SRP几乎总是导致更多代码＆＃34;但它是干净，可读和可维护的代码。

包装原始类型的优点？

2 个答案: