设计模式 || 职责链
“我要涨工资！！”
“好，那你打份申请表吧：涨50让你主管签个字，涨500让你主管和部门经理签字，涨5000让你主管和部门经理和人事经理签字，涨50000，你就让你主管和部门经理和人事经理和老板签字，如果没批准，你这个牛宝宝就翻滚吧！”
于是，你就抱着申请单，去找主管、找部门经理、找人事经理、找老板……
停！何须如此麻烦，责任链，上！
不管是主管，还是部门经理、人事经理甚至老板，他们在我这里，就只是两个字：领导！
抽象它！
abstract class Leader{}
而此刻，他们对我来说，都只有一个作用：签字！
给他统一个名字：
abstract class Leader{
abstract public function singleup();//抽象类，必须有一个抽象方法
}
上面的这个接口（interface定义的都是抽象类），你看它是不是只有个名字？领导这个词是不是很宽呀？接下来，我们就将它具象化：
//引入接口就省略了哈
class 主管 extends Leader{
public function singleup($money){
if ($money <= 50){
return "批准啦！";
}else{
echo "组长批准，但还需要部门经理批准！";
return $this->Leader->singleup();
}
}
}
class 部门经理 implement Leader{
public function singleup($money){
if ($money <= 500){
return "批准啦！";
}else{
echo "部门经理批准，但还需要人事经理批准！";
return $this->Leader->singleup();
}
}
}
class 人事经理 implement Leader{
public function singleup($money){
if ($money <= 5000){
return "批准啦！";
}else{
echo "人事经理批准，但还需要老板批准！";
return $this->Leader->singleup();
}
}
}
class 老板 implement Leader{
public function singleup($money){
echo "牛宝宝，你跑快点，梦想在外面！";
}
}
问题来了，这不还是得自己一个一个领导跑嘛？
别急，给领导们都加一个空间传送阵！让超出范围的审批自动传送到上级领导那去！
abstract class Leader{
protected $leader;
abstract public function singleup();//抽象类，必须有一个抽象方法
public function setLeader($leader) {//如果自己权限不够，就传送给上级领导
$this->leader=$leader;
}
}
激动激动，我好想找老板签字~~赶紧准备申请书！
//实例化每个领导
$zhuguan = new 主管();
$bumenjingli = new 部门经理();
$renshijingli = new 人事经理();
$laoban = new 老板();
//准备好传送流程
$zhuguan ->setLeader($bumenjingli );
$bumenjingli ->setLeader($renshijingli );
$renshijingli ->setLeader($laoban );
我要涨50000！
$zhuguan ->singup(50000);
你猜输出什么？我猜：
组长批准，但还需要部门经理批准！
部门经理批准，但还需要人事经理批准！
人事经理批准，但还需要老板批准！
牛宝宝，你跑快点，梦想在外面！
啊哦~一下回到解放前，所以咱还是低调点，嘻嘻~
作者言：每一个设计模式的使用都不是固定的，需要根据自己的具体业务做适当的修改。
