包装原始类型的优势？

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在该方法的行为方面意味着什么。我是说，字面上写着“重绘错误”，所以...重新粉刷但是..。不是真的重画吗？意图并不明确，这是一件坏事。

这个极其简单的示例演示了如何通过包装原语来极大地提高代码的可读性。当您想要开始添加一些行为时，好处甚至更大，比如在简单的验证中进行烘焙，并将其自身与另一个实例进行比较。

对于创建这么小的一个小对象对性能的影响，你应该一点也不关心。至于“更多的代码行”有什么不好呢？SRP几乎总是产生“更多的代码”，但它是干净、可读和可维护的代码。