前言

之前的一個(gè)同事?lián)Q工作，在面試被問到了 PHP 的 trait 。因?yàn)闆]用過， 所以沒答好，我大概是用過幾次的，想了想整理了以下的總結(jié)。

trait

trait 是在一些類(Class)的應(yīng)該具備的特定的屬性或方法,而同父級(jí)的另外一些類應(yīng)該避免包含這些屬性和方法情況下使用的.

當(dāng)然, 這也和開發(fā)者對(duì)類的抽象能力有關(guān), 有些抽象能力好的, 可以減少對(duì) trait 的使用 但是這種情況應(yīng)該是無法避免的 不然 trait 出現(xiàn)就毫無意義了.

還有一種情況, 就是使用 trait 的時(shí)候, 可以起到的約束開發(fā)者的作用, 提醒開發(fā)者注意需要在開發(fā)的過程中調(diào)用 trait 的某些屬性和方法.

同事則提出了一個(gè)好問題, 接口(interface) 不也是這個(gè)作用么?

不急, 讓我們先看個(gè)例子:

比如你要收集網(wǎng)站上各類數(shù)據(jù), 開發(fā)了 Spider 類. Spider 有個(gè)方法叫 request() 負(fù)責(zé)請(qǐng)求.

<?php namespace XWSoul\Network;
class Spider
{
 public function request($url)
 {
 //do sth.
 }
}

但是采集數(shù)據(jù)的過程中, 有些網(wǎng)站對(duì)蜘蛛敏感有些則不. 對(duì)于敏感的網(wǎng)站, 我們給出了一個(gè)使用代理的解決方案. 但是使用代理是會(huì)影響抓取速度的. 這就產(chǎn)生了 Spider 的子類有些需要用代理, 而能不用代理則盡量不用的情況.

于是這個(gè)時(shí)候我們新增了一個(gè) trait Proxy:

<?php namespace XWSoul\Network;
trait Proxy
{

 protected $isProxy = false;

 public function useProxy($proxy)
 {
 //do sth proxy setups.
 $this->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() 方法, 限定了在沒有調(diào)用代理的情況下調(diào)用會(huì)拋出異常.

回到之前的問題, trait 這樣的用法和 接口(interface) 有什么區(qū)別?

接口的約束是前置的是定義初始就必須實(shí)現(xiàn)的, 他可以約束方法的實(shí)現(xiàn)卻無法約束方法的調(diào)用, trait 是一種后置的調(diào)用, 他已經(jīng)實(shí)現(xiàn)了方法, 關(guān)鍵的是, 他只對(duì)調(diào)用了自身的類產(chǎn)生約束(廢話一句), 而對(duì)沒有調(diào)用自身的類不產(chǎn)生影響(再一句廢話), 同時(shí)他是可復(fù)用的, 而且沒有破壞 Spider 類自身的實(shí)現(xiàn)增加, Spider 還是那個(gè) Spider.

我想 trait 的用法再這里已經(jīng)很有效了吧.

后話

有人可能決定 另外實(shí)現(xiàn)一個(gè) request 比如叫, proxyRequst 不就完了么? 你說的好有道理…然是如果我使用了不一樣的 代理具體對(duì)請(qǐng)求上有細(xì)節(jié)差異怎么辦呢? 在代碼里不停的 if if if 么? trait 如此清爽的方案 為何要放棄呢?

總結(jié)

好了，以上就是這篇文章的全部內(nèi)容了希望本文的內(nèi)容對(duì)大家的學(xué)習(xí)或者工作能帶來一定的幫助，如果有疑問大家可以留言交流。

最新評(píng)論