加薪非要老总批?——职责链模式

加薪非要老总批?——职责链模式

继上一篇“烤羊肉串引来的思考——命令模式”后,本文继续讲解《大话设计模式》第24章“加薪非要老总批?——职责链模式”。喜欢本书请到各大商城购买原书,支持正版。

大话设计模式前期读书系列:

本文正式开始


1 老板,我要加薪!

时间:7月2日20点 地点:小菜大鸟住所的客厅 人物:小菜、大鸟

“大鸟,你说我现在干满三个月了,马上要办转正手续,我提提加薪的事情好不好?”小菜问道。

“这要看你这三个月做得如何了。”

“我和刚进来的几个同事比较,我觉得我做得很好。公司每每分配的任务,我基本都可以快速完成。有一次,一段程序需要增加一个分支条件,我立刻想到利用反射、工厂等设计模式来处理,经理对我的设计很满意。”

“哦,学以致用,那是最好不过了。那你不妨向你们经理提一提,你现在那点收入确实也有被剥削之嫌。”

“有你这话,我决定了,明天就向经理说。”

“加薪后如何办啊?”

“哦!知道。请你吃炒面。”

“炒面?搞没搞错,我要吃龙虾!”

“好的好的,大龙虾不敢说,小龙虾还是没问题的。”小菜伸了伸舌头笑道。

时间:7月3日19点 地点:小菜大鸟住所的客厅 人物:小菜、大鸟

“小菜,是不是该去吃龙虾了?”大鸟下班回来问道。

“嗨!别提了,不让加。”

“嗯?为什么?”

“今天一早,我对经理如实说了我的想法,希望公司能在转正时增加我的工资待遇。经理说这个情况他也了解,并肯定地说,我的工作很认真,我的能力很强。但加薪他做不了主,他帮我向上提一提。而后他去找了人力资源总监,总监说这事他也做不了主,毕竟刚毕业的大学生加薪的先例没有,但总监说,等总经理来后,向总经理提一提这个事。”

“哈,加个薪,流程走了不少呀,后来如何?”

“我从经理那里得到的消息是,总经理不同意加薪,因为现在大学毕业生这么多,随便都能找得到。三个月就想加薪,不合适。”

“这哪和哪呀,大学毕业生多就会贬值呀,这没道理的。加不加薪,还是要看能力,看贡献。”大鸟愤慨地说。

“是呀,我也觉得非常不爽。我们经理说完这话,叫我安心,他会再努力努力。我感觉他其实也是很无奈的。”

“看来你们经理还是很体谅程序员的苦衷。不过你也别抱太大的希望,总经理不同意,基本就没希望了。”

“是呀,这种不重能力,只重资历的公司待着也没劲哦。你说我是不是该考虑换一换?”

“小子,你才毕业呀,刚工作就想跳槽,心态也太不好了吧。”

“嗨,不提了。今天我们学习哪个模式?”

“你把今天你向经理申请,经理没权利,然后向总监上报,总监也没权限,向总经理上报的事,写成代码来看看吧,注意哦,不一定是加薪,还有可能是请假申请等等。”

“哦,难道这也是模式?我试试看。”

2 加薪代码初步

“实现这个场景感觉有些难度哦!”

“首先我觉得无论加薪还是请假,都是一种申请。申请就应该有申请类别、申请内容和申请数量。”

//申请
class Request
{
  //申请类别
  private string requestType;
  public string RequestType
  {
    get { return requestType; }
    set { requestType = value; }
  }
  
  //申请内容
  private string requestContent;
  public string RequestContent
  {
    get { return requestContent; }
    set { requestContent = value: }
  }
  
  //数量
  private int number;
  public int Number
  {
    get { return number; }
    set { number = value; }
  }
}

“然后我觉得经理、总监、总经理都是管理者,他们在对‘申请’处理时,需要做出判断,是否有权决策。”

//管理者
class Manager
{
  protected string name;  
  public Manager(string name)
  {
    this.name = name;,
  }
  
  //得到结果
  public void GetResult(string managerLevel, Request request)
  {
    if(managerLevel ==“经理")
    {
      if (request.RequestType =="请假" && request.Number <= 2)
      {
        Console.WriteLine("{0}:{1}数量{2}被批准",name,request.RequestContent, request.Number) ;
      }
      else
      {
        Console.WriteLine("{0}:{1}数量{2}我无权处理", name, request.RequestContent, request.Number);
      }
    }
    else if(managerLevel == "总监")
    {
      if (request.RequestType =="请假" && request.Number <= 5)
      {
        Console.WriteLine("{0}:{1}数量{2}被批准", name, request.RequestContent, request.Number);
      }
      else 
      {
        Console.WriteLine("{0}:{1}数量{2}我无权处理", name, request.RequestContent, request.Number);
      }
    }
    else if(managerLevel == “总经理")
    {
      if (request.RequestType == "请假")
      {
        Console.WriteLine("{0}:{1}数量{2}被批准”,name, request.RequestContent, request.Number);
      }
      else if (request.RequestType == "加薪" && request.Number <= 500)
      {
        Console.WriteLine("{0}:{1}数量{2}被批准",name, request.RequestContent, request.Number) ;
      }
      else if (request.RequestType == "加薪" && request.Number > 500)
      {
        Console.WriteLine("{0]:{1}数量{2}再说吧", name,request.RequestContent, request.Number);
      }
    }
  }
}

客户端代码如下

static void Main(string[] args)
{
  // 三个管理者
  Manager jinli = new Manager(""金利");
  Manager zongjian = new Manager("宗剑");
  Manager zhongjingli = new Manager("钟精励");
  
  // 小菜请求加薪1000
  Request request = new Request();
  request.RequestType =“加薪";
  request.RequestContent ="小菜请求加薪";  
  request. Number = 1000;
  
  //不同的级别对此请求做判断和处理
  jinli.GetResult("经理",request);
  zongjian.GetResult(”总监”,request);  
  zhongjingli.GetResult("总经理",request);
  
  // 小菜请假3天
  Request request2 =new Request();
  request2.RequestType = “请假":
  request2.RequestContent ="小菜请假";
  request2 .Number = 3;
  
  jinli.GetResult("经理",request2);
  zongjian.GetResult(总监",request2);
  zhongjingli.GetResult《("总经理",request2);
  
  Console.Read();
}

“其实我自己也觉得写得不怎么好。”小菜说道,“但也不知道如何去处理这类问题。”

“哪里写得不好?”大鸟问道。

“那个‘管理者’类吧,里面的‘结果’方法比较长,加上有太多的分支判断,这其实是非常不好的设计。”

“说得不错,因为你很难讲当中还会不会增加其他的管理类别,比如项目经理、部门经理、人力总监、副总经理等等。那就意味着都需要去更改这个类,这个类承担了太多的责任,这违背了哪些设计原则?”

“类有太多的责任,这违背了单一职责原则,增加新的管理类别,需要修改这个类,违背了开放-封闭原则。”

“说得好,那你觉得应该如何下手去重构它呢?”

“你刚才提到了可能会增加管理类别,那就意味着这里容易变化,我想把这些公司管理者的类别各做成管理者的子类,这就可以利用多态性来化解分支带来的僵化。”

“那如何解决经理无权上报总监,总监无权再上报总经理这样的功能呢?”

“我想让它们之间有一定的关联,把用户的请求传递,直到可以解决这个请求为止。”

“说得不错,你其实已经说到了一个行为设计模式‘职责链模式’的意图了。”

3 职责链模式

职责链模式(Chain of Responsibility):使多个对象都有机会处理请求,从而避免请求的发送者和接收者之间的耦合关系。将这个对象连成一条链,并沿着这条链传递该请求,直到有一个对象处理它为止。[DP]

“这里发出这个请求的客户端并不知道这当中的哪一个对象最终处理这个请求,这样系统的更改可以在不影响客户端的情况下动态地重新组织和分配责任。”

“听起来感觉不错哦,但如何做呢?”

“我们来看看结构图。”

职责链模式(Chain of Responsibility)结构图

加薪非要老总批?——职责链模式

Handler类,定义一个处理请示的接口。

abstract class Handler
{
  protected Handler successor;
  
  // 设置继任者
  public void SetSuccessor(Handler successor)
  {
    this.successor = successor;
  }
    
  // 处理请求的抽象方法
  public abstract void HandleRequest(int request);
}

ConcreteHandler类,具体处理者类,处理它所负责的请求,可访问它的后继者,如果可处理该请求,就处理之,否则就将该请求转发给它的后继者。

ConcreteHandler1,当请求数在0到10之间则有权处理,否则转到下一位。

class concreteHandlerl :Handler
{
  public override void HandleRequest(int request)
  {
    // 0到10,处理此请求
    if (request >= 0 && request < 10)    
    {
      Console.WriteLine("{0}处理请求{1}", this.GetType().Name, request);
    }
    else if (successor != null)
    {
      // 转移到下一位
      successor.HandleRequest(request);
    }
  }
}

ConcreteHandler2,当请求数在10到20之间则有权处理,否则转到下一位。

class conereteHandler2 : Handler
{
  public override void HandleRequest(int request)
  {
    // 10到20,处理此请求
    if(request >= 10 && request < 20}
    {
      Console.WriteLine("{0]处理请求{1}", this.GetType().Name, request):
    }
    else if (successor !=null)
    {
      // 转移到下一位
      successor.HandleRequest(request);
    }
  }
}

ConcreteHandler3,当请求数在20到30之间则有权处理,否则转到下一位。

class concreteHandler3 : Handler
{
  public override void HandleRequest(int request)
  {
    // 20到30,处理此请求
    if(request >= 20 && request < 30}
    {
      Console.WriteLine("{0]处理请求{1}", this.GetType().Name, request):
    }
    else if (successor !=null)
    {
      // 转移到下一位
      successor.HandleRequest(request);
    }
  }
}

客户端代码,向链上的具体处理者对象提交请求。

static void Main (string[] args)
{
  Handler hl = new ConcreteHandler1();
  Handler h2 = new ConcreteHandler2();
  Handler h3 = new ConcreteHandler3();
  
  // 设置职责链上家与下家
  h1.SetSuccessor(h2);
  h2.SetSuccessor(h3);
  
  int[] requests = { 2, 5,14, 22, 18, 3,27,20 };
  
  // 循环给最小处理者提交请求,不同的数额,由不同权限处理者处理
  foreach (int request in requests)  
  {
    hl.HandleRequest(request);
  }
  
  Console.Read() ;
}

4 职责链的好处

“这当中最关键的是当客户提交一个请求时,请求是沿链传递直至有一个ConcreteHandler对象负责处理它。[DP]

“这样做的好处是不是说请求者不用管哪个对象来处理,反正该请求会被处理就对了?”

“是的,这就使得接收者和发送者都没有对方的明确信息,且链中的对象自己也并不知道链的结构。结果是职责链可简化对象的相互连接,它们仅需保持一个指向其后继者的引用,而不需保持它所有的候选接受者的引用[DP]。这也就大大降低了耦合度了。”

“我感觉由于是在客户端来定义链的结构,也就是说,我可以随时地增加或修改处理一个请求的结构。增强了给对象指派职责的灵活性[DP]。”

“是的,这的确是很灵活,不过也要当心,一个请求极有可能到了链的末端都得不到处理,或者因为没有正确配置而得不到处理,这就很糟糕了。需要事先考虑全面。”

“哈,这就跟现实中邮寄一封信,因地址不对,最终无法送达一样。”

“是的,就是这个意思。就刚才的例子而言,最重要的有两点,一个是你需要事先给每个具体管理者设置他的上司是哪个类,也就是设置后继者。另一点是你需要在每个具体管理者处理请求时,做出判断,是可以处理这个请求,还是必须要‘推卸责任’,转移给后继者去处理。”

“哦,我明白你的意思了,其实就是把我现在写的这个管理者类当中的那些分支,分解到每一个具体的管理者类当中,然后利用事先设置的后继者来实现请求处理的权限问题。”

5 加薪代码重构

“是的,所以我们先来改造这个管理者类,此时它将成为抽象的父类了,其实它就是Handler。”

代码结构图

加薪非要老总批?——职责链模式
//管理者
abstract class Manager
{
  protected string name;
  
  //管理者的上级
  protected Manager superior;
  
  public Manager(string name)
  {
    this.name name;
  )
  
  // 关键的方法,设置管理者的上级
  // 设置管理者的上级
  public void SetSuperior(Manager superior)
  {
    this.superior = superior;
  }
  
  //申请请求
  abstract public void RequestApplications(Request request);
}

“经理类就可以去继承这个‘管理者’类,只需重写‘申请请求’的方法就可以了。”

//经理
class CommonManager : Manager
{
  public CommonManager(string name)
  : base (name)
  { }
  
  
  public override void RequestApplications(Request request)
  {
    // 经理所能有的权限就是可准许下属两天内的假期
    if (request.RequestType == "请假" && request.Number <= 2)
    {
      Console.WriteLine("{0}:{1]数量{2}被批准", name, request.RequestContent, request.Number);
    }
    //其余的申请都需转到上级
    else
    {
      if (superior != null)
      {
        superior.RequestApplications(request);
      }
    }
  }
}

“‘总监’类同样继承‘管理者类”。”

// 总监
class Majordomo : Manager
{
  public Majordomo(string name)
  : base (name)
  { }  
  
  public override void RequestApplications(Request request)
  {
    // 总监所能有的权限就是可准许下属一周内的假期
    if (request.RequestType == "请假" && request.Number <= 5)
    {
      Console.WriteLine("{0}:{1]数量{2}被批准", name, request.RequestContent, request.Number);
    }
    //其余的申请都需转到上级
    else
    {
      if (superior != null)
      {
        superior.RequestApplications(request);
      }
    }
  }
}

“‘总经理’的权限就是全部都需要处理。“

// 总经理
class GeneralManager : Manager
{
  public GeneralManager(string name)
  : base (name)
  { }  
  
  public override void RequestApplications(Request request)
  {
    // 总经理可准许下属任意天的假期
    if (request.RequestType == "请假")
    {
      Console.WriteLine("{0}:{1]数量{2}被批准", name, request.RequestContent, request.Number);
    }
    // 加薪在500以内,没有问题
    else if (request.RequestType == "加薪" && request.Number <= 500)
    {
      Console.WriteLine($"{name}:{request.RequestContent} 数量{request.Number}被批准")
    }
    // 超过500,就要考虑一下了
    else if (request.RequestType == "加薪" && request.Nubmer > 500)
    {
      Console.WriteLine($"{name}:{request.RequestContent} 数量{request.Number} 再说吧")
    }
  }
}

“由于我们把你原来的一个‘管理者’类改成了一个抽象类和三个具体类,此时类之间的灵活性就大大增加了,如果我们需要扩展新的管理者类别,只需要增加子类就可以。当然,还有一个关键,那就是客户端如何编写。”

static void Main(string[] args)
{
  CommonManager jinli = new CommonManager(""金利");
  Majordomo zongjian = new Majordomo("宗剑");
  GeneralManager zhongjingli = new GeneralManager("钟精励");
  
  //设置上级,完全可以根据实际需求来更改设置
  jinli.SetSuperior(zongjian);
  zongjian.SetSuperior(zhongjingli);  
  
  // 客户端的申请都是由‘经理’发起,但实际谁来决策由具体管理类来处理,客户端不知道

  
  // 小菜请求加薪1000
  Request request = new Request();
  request.RequestType =“请假";
  request.RequestContent ="小菜请求请假";  
  request.Number = 1;
  jinli.RequestApplications(request);
  
  // 小菜请假4天
  Request request2 =new Request();
  request2.RequestType = “请假":
  request2.RequestContent ="小菜请假";
  request2 .Number = 4;
  jinli.RequestApplications(request2);
  
  Request request3 =new Request();
  request3.RequestType = “加薪":
  request3.RequestContent ="小菜请求加薪";
  request3 .Number = 500;
  jinli.RequestApplications(request3);
  
  Request request4 =new Request();
  request4.RequestType = “加薪":
  request4.RequestContent ="小菜请求加薪";
  request4 .Number = 1000;
  jinli.RequestApplications(request4);
  
  Console.Read();
}

结果显示

金利: 小菜请假 数量1 被批准
宗剑: 小菜请假 数量4 被批准
钟精励: 小菜请求加薪 数量500 被批准
钟精励: 小菜请求加薪 数量1000 再说吧

“嗯,这的确是很好地解决了原来大量的分支判断造成难维护、灵活性差的问题。”

6 加薪成功

正在此时,小菜的手机响了起来。

“喂,”小菜说,“李经理,您好。”

“小蔡呀,是这样,我刚才又去找总经理了,向他也汇报了这一段时间你的工作情况,你的积极表现和非常优秀的编程能力总经理也是非常肯定的。所以他最终答应了你的申请,给你加薪,从下个月开始实施。”小菜的经理在电话那边说道。

“啊,是吗!真的谢谢您,万分感谢。回头我请您吃饭。嗯,好的,好的,OK,拜拜。”小菜脸上笑开了花。

“你这马屁精,干吗不跳槽了?不是说要跳的吗?”

“还跳什么槽呀。我这经理人真的不错,还专门去帮我找总经理谈,太为下属着想了。”

“哈,事实上,他是改变了职责链的结构,跳过了总监直接找总经理处理这事,这也体现了职责链灵活性的一个方面。”

“对的对的,设计模式真是无处不在呀。”小菜笑着说,“走,我请你吃炒面去。”

“谁说是炒面,我讲过的,我要吃的是——龙虾。”


每天学一点,不贪多。

下一篇我们接着读“第25章 世界需要和平——中介者模式”,欢迎关注微信公众号【乐趣课堂】。

原文出处:微信公众号【乐趣课堂】

原文链接:

本文观点不代表Dotnet9立场,转载请联系原作者。

发表评论

登录后才能评论