PHP - Traits作为辅助工具

Question

使用 Trait 来注入辅助方法是否存在任何矛盾？

   class Foo
   {
 use Helper\Array;
function isFooValid(array $foo)
       {
            return $this->arrayContainsOnly('BarClass', $foo);
       }
}

- Mateusz Charytoniuk

---

这可能更适合于代码审查。它在这里有些不太相关。 - Ja͢ck

Answer 1

这就是trait的设计目的。

但是，您仍然应该注意耦合代码的问题。如果Helper\Array和Foo所在的命名空间完全不同，您可能需要重新考虑这种特定的方法。

- Tobias Sjösten

---

我想避免使用像 ArrayHelper::arrayContainsOnly('BarClass', $foo) 这样的通用帮助类，并在整个项目中使用适当的 traits 替换它们。类的命名空间可能会有所不同。这是否意味着这种方法仍然是正确的？ - Mateusz Charytoniuk

这样使用单例模式是正确的。但是在这两种情况下，我更愿意使用一个Arrayer库，你可以实例化并注入到你的Foo类中。这样它们之间就不必紧密耦合，当测试代码时，你可以轻松地替换其中一个。 - Tobias Sjösten

Answer 2

在PHP中添加了Traits，其原因很简单：PHP不支持多重继承。简单来说，一个类不能同时继承多个类。当您需要使用其他类使用的两个不同类中声明的功能时，这变得费力，结果是您必须重复代码以完成工作，否则就会陷入一片混乱中。

进入traits。它们允许我们声明一种包含可重用方法的类类型。更好的是，它们的方法可以直接注入到任何您使用的类中，而且您可以在同一个类中使用多个traits。让我们看一个简单的Hello World示例。

<?php

trait SayHello
{
    private function hello()
    {
        return "Hello ";
    }

    private function world()
    {
        return "World";
    }
}

trait Talk
{
    private function speak()
    {
        echo $this->hello() . $this->world();
    }
}

class HelloWorld
{
    use SayHello;
    use Talk;

    public function __construct()
    {
        $this->speak();
    }
}

$message = new HelloWorld(); // returns "Hello World";

- PankajR

Answer 3

在我看来，谈到应用程序内的凝聚力时，分配责任是一件好事，但散布责任则与契约设计无关。这就是我对辅助特征的担忧。我一直在思考特征在架构中的位置，我真的认为特征应该被看作是共享实现，意味着共享封装。因此，它们不应该取代接口，而是留在接口背后。我将“接口”理解为架构和语言无关的概念，而不是PHP特定接口的个人理解，因为PHP特定接口只是抽象工具，而特征只是实现工具。接口先于实现。依赖于抽象/接口而不是具体/细节。因此，重要的是要记住，特征不会构建应用程序架构，也不会启动类合同，而是站在它们的后面并为它们服务。

- Cyril