來公司快一年了終於可以去出差了,出差回來就是寫出差報銷流程。公司規定報銷金額小於3000直屬領導可以批,大於3000小於10000部門領導可以批,大於10000需要boss才能批(每個公司不一樣),下面用程序猿的語言來描述這個流程。
程序猿:
public class Programer
{
private int money;
private String request ="出差報銷";
public Programer(int money)
{
this.money = money;
}
public int getMoney()
{
return money;
}
public void setMoney(int money)
{
this.money = money;
}
/*
* 獲取差旅費申請
*/
public String getApply() {
return request;
}
}
直屬領導:
public class GroupLeader
{
public void handleRequest(Programer p)
{
System.out.println(p.getApply());
System.out.println("groupleader is ok");
}
}
部門經理:
public class Manager
{
public void handleRequest(Programer p)
{
System.out.println(p.getApply());
System.out.println("manager is ok");
}
}
老闆Boss:
public class Boss
{
public void handleRequest(Programer p)
{
System.out.println(p.getApply());
System.out.println("boss is ok");
}
}
場景類:
public class Client
{
public static void main(String[] args)
{
Programer p = new Programer(4000);
GroupLeader leader = new GroupLeader();
Manager manager = new Manager();
Boss boss = new Boss();
if(p.getMoney()>1000)
{
leader.handleRequest(p);
}else if (p.getMoney()<10000) {
manager.handleRequest(p);
}else {
boss.handleRequest(p);
}
}
}
報銷流程結果:
出差報銷
groupleader is ok
整個報銷流程走完了,我們發現這段代碼太粗糙了,審批流程的過程應該由領導自己來完成,而不是放在場景類中。我們把領導抽象出來,讓流程審批邏輯由領導自己審批,改造後代碼如下所示:
抽象領導類:
public abstract class Leader
{
private int money;//領導能批的最大金額
private Leader supLeader;//上級領導
public Leader(int money)
{
this.money = money;
}
public void setSupLeader(Leader supLeader)
{
this.supLeader = supLeader;
}
public void handleRequest(Programer p)
{
if(p.getMoney()<=this.money)
{
apply(p);
}else {
if(supLeader!=null)
{
supLeader.apply(p);
}else{
System.out.println("流程出錯,審批失敗");
}
}
}
public abstract void apply(Programer p);//批流程
}
直屬領導:
public class GroupLeader extends Leader
{
public GroupLeader()
{
super(3000);
// TODO Auto-generated constructor stub
}
@Override
public void apply(Programer p)
{
System.out.println(p.getApply());
System.out.println("groupLeader is ok");
}
}
部門經理:
public class Manager extends Leader
{
public Manager()
{
super(10000);
// TODO Auto-generated constructor stub
}
@Override
public void apply(Programer p)
{
System.out.println(p.getApply());
System.out.println("manager is ok");
}
}
老闆boss:
public class Boss extends Leader
{
public Boss()
{
super(10000);
// TODO Auto-generated constructor stub
}
@Override
public void apply(Programer p)
{
// TODO Auto-generated method stub
System.out.println(p.getApply());
System.out.println("boss is ok");
}
}
程序猿:
public class Programer
{
private int money;
private String request ="出差報銷";
public Programer(int money)
{
this.money = money;
}
public int getMoney()
{
return money;
}
public void setMoney(int money)
{
this.money = money;
}
/*
* 獲取差旅費申請
*/
public String getApply() {
return request;
}
}
場景類:
public class Client
{
public static void main(String[] args)
{
Programer programer = new Programer(4000);
GroupLeader groupLeader = new GroupLeader();
Manager manager = new Manager();
Boss boss = new Boss();
groupLeader.setSupLeader(manager);
manager.setSupLeader(boss);
groupLeader.handleRequest(programer);
}
}
流程審批結果:
public class Client
{
public static void main(String[] args)
{
Programer programer = new Programer(4000);
GroupLeader groupLeader = new GroupLeader();
Manager manager = new Manager();
Boss boss = new Boss();
groupLeader.setSupLeader(manager);
manager.setSupLeader(boss);
groupLeader.handleRequest(programer);
}
}
結果是一樣的,我們場景類裏只是給領導設置了上級領導就可以完成整個報銷流程的審批。流程請求和流程處理完全分開,程序猿不需要知道是誰審批了這個流程,儘管收錢就好,這就是責任鏈模式。
責任鏈模式定義
責任鏈模式:Avoid couping the sender of a request to its receiver by giving more than one object a chance to handle the quest. Chain the receiving objects and pass the request along the chain until an object handles it.(使多個對象都有機會處理請求類,從而避免了請求的發送者和接收者之間的耦合關係。將這些對象連成一條鏈,並沿着這條鏈傳遞該請求,直到有對象處理它爲止)。
責任鏈模式的優點
責任鏈模式將請求和處理分開,請求者可以不知道處理者是誰,處理者也不用知道請求者是誰。
責任鏈模式的缺點
性能問題,每個請求都是從鏈頭遍歷到尾,責任鏈如果很長時,性能就是一個大問題。
責任鏈在Android中的使用
Android中view的事件分發就是使用了責任鏈模式。