前同事换工作, 面试被问到了 PHP 的 trait . 因为没用过, 所以没答好.
我大概是用过几次的, 想了想 整理了以下的总结.
trait 是在一些类(Class)的应该具备的特定的属性或方法,而同父级的另外一些类应该避免包含这些属性和方法情况下使用的.
当然, 这也和开发者对类的抽象能力有关, 有些抽象能力好的, 可以减少对 trait 的使用 但是这种情况应该是无法避免的 不然 trait 出现就毫无意义了.
还有一种情况, 就是使用 trait 的时候, 可以起到的约束开发者的作用, 提醒开发者注意需要在开发的过程中调用 trait 的某些属性和方法.
同事则提出了一个好问题, 接口(interface) 不也是这个作用么?
不急, 让我们先看个例子:
比如你要收集网站上各类数据, 开发了 Spider 类. Spider 有个方法叫 request() 负责请求.
但是采集数据的过程中, 有些网站对蜘蛛敏感有些则不. 对于敏感的网站, 我们给出了一个使用代理的解决方案. 但是使用代理是会影响抓取速度的. 这就产生了 Spider 的子类有些需要用代理, 而能不用代理则尽量不用的情况.
于是这个时候我们新增了一个 trait Proxy:
isProxy = true; return $this; } public function request($url) { if (!$this->isProxy) { throw new Exception("Please using proxy."); } //do sth. return parent::request($url); } }trait 重写了 Spider 的 request() 方法, 限定了在没有调用代理的情况下调用会抛出异常.
回到之前的问题, trait 这样的用法和 接口(interface) 有什么区别?
接口的约束是前置的是定义初始就必须实现的, 他可以约束方法的实现却无法约束方法的调用, trait 是一种后置的调用, 他已经实现了方法, 关键的是, 他只对调用了自身的类产生约束(废话一句), 而对没有调用自身的类不产生影响(再一句废话), 同时他是可复用的, 而且没有破坏 Spider 类自身的实现增加, Spider 还是那个 Spider.
我想 trait 的用法再这里已经很有效了吧.
后话: 有人可能决定 另外实现一个 request 比如叫, proxyRequst 不就完了么? 你说的好有道理...然是如果我使用了不一样的 代理具体对请求上有细节差异怎么办呢? 在代码里不停的 if if if 么? trait 如此清爽的方案 为何要放弃呢?
