文章目录
- 加薪非要老总批？——职责链模式
- 加薪代码初步
- 职责链模式
- 职责链的好处
- 加薪代码重构
- 加薪成功
加薪非要老总批？——职责链模式
老板，我要加薪！
时间：7月2日20点 地点：小菜、大鸟住所的客厅 人物：小菜、大鸟
"大鸟，你说我现在干满三个月了，马上要办转正手续，我提提加薪的事情好不好？"小菜问道。
“这要看你这三个月做得如何了。”
“我和刚进来的几个同事比较，我觉得我做得很好。公司每每分配的任务，我基本都可以快速完成。有一次，一段程序需要增加一个分支条件，我立刻想到利用反射、工厂等设计模式来处理，经理对我的设计很满意。”
“哦，学以致用，那是最好不过了。那你不妨向你们经理提一提，你现在那点收入确实也有被剥削之嫌。”
“有你这话，我决定了，明天就向经理说。”
“加薪后如何办啊？”
“哦！知道。请你吃炒面。”
“炒面？搞没搞错，我要吃龙虾！”
"好的好的，大龙虾不敢说，小龙虾还是没问题的。"小菜伸了伸舌头笑道。
时间：7月3日19点 地点：小菜大鸟住所的客厅 人物：小菜、大鸟
"小菜，是不是该去吃龙虾了？"大鸟下班回来问道。
"唉！别提了，不让加。今天一早，我对经理如实说了我的想法，希望公司能在转正时增加我的工资待遇。经理说这个情况他也了解，并肯定地说，我的工作很认真，我的能力很强。但加薪他做不了主，他帮我向上提一提。
而后他去找了人力资源总监，总监说这事他也做不了主，毕竟刚毕业的大学生加薪的先例没有，但总监说，可以向总经理提一提这个事。"
“哈，加个薪，流程走了不少呀，后来如何？”
“我从经理那里得到的消息是，总经理不同意加薪，因为现在大学毕业生这么多，随便都能找得到。三个月就想加薪，不合适。”
"这哪和哪呀，大学毕业生多就会贬值呀，这没道理的。加不加薪，还是要看能力，看贡献。"大鸟愤慨地说。
“是呀，我也觉得非常不爽。我们经理说完这话，叫我安心，他会再努力努力。我感觉他其实也是很无奈的。”
“看来你们经理还是很体谅程序员的苦衷。不过你也别抱太大的希望，总经理不同意，基本就没希望了。”
“是呀，这种不重能力、只重资历的公司待着也没劲哦。是不是该考虑换一换？”
“小子，你才毕业呀，刚工作就想跳槽，心态也太不好了吧。”
“唉，不提了。今天我们学习哪个模式？”
“你把今天你向经理申请，经理没权利，然后向总监上报，总监也没权限，向总经理上报的事，写成代码来看看吧，注意哦，不一定是加薪，还有可能是请假申请等。”
“哦，难道这也是模式？我试试看。”
加薪代码初步
“实现这个场景感觉有些难度哦！”
“首先我觉得无论加薪还是请假，都是一种申请。申请就应该有申请类别、申请内容和申请数量。”
“然后我觉得经理、总监、总经理都是管理者，他们在对’申请’处理时，需要做出判断，是否有权决策。”
客户端代码：
"其实我自己也觉得写得不好。"小菜说，“但也不知道如何去处理这类问题。”
"哪里写得不好？"大鸟问道。
“那个’管理者’类吧，里面的’结果’方法比较长，加上有太多的分支判断，这其实是非常不好的设计。”
“说得不错，因为你很难讲当中还会不会增加其他的管理类别，比如项目经理、部门经理、人力总监、副总经理等。那就意味着都需要去更改这个类，这个类承担了太多的责任，这违背了哪些设计原则？”
“类有太多的责任，这违背了单一职责原则，增加新的管理类别，需要修改这个类，违背了开放-封闭原则。”
“说得好，那你觉得应该如何下手去重构它呢？”
“你刚才提到了可能会增加管理类别，那就意味着这里容易变化，我想把这些公司管理者的类别分别做成管理者的子类，这就可以利用多态性来化解分支带来的僵化。”
“那如何解决经理无权上报总监，总监无权再上报总经理这样的功能呢？”
“我想让它们之间有一定的关联，把用户的请求传递，直到可以解决这个请求为止。”
“说得不错，你其实已经说到了一个行为设计模式’职责链模式’的意图了。”
职责链模式
职责链模式（Chain of Responsibility）：使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这个对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。［DP］
“这里发出这个请求的客户端并不知道这当中的哪一个对象最终处理这个请求，这样系统的更改可以在不影响客户端的情况下动态地重新组织和分配责任。”
“听起来感觉不错哦，但如何做呢？”
“我们来看看结构图。”
Handler类，定义一个处理请示的接口。
ConcreteHandler类，具体处理者类，处理它所负责的请求，可访问它的后继者，如果可处理该请求，就处理之，否则就将该请求转发给它的后继者。
ConcreteHandler1，当请求数为0~10则有权处理，否则转到下一位。
客户端代码，向链上的具体处理者对象提交请求。
职责链的好处
“这当中最关键的是当客户提交一个请求时，请求是沿链传递直至有一个ConcreteHandler对象负责处理它。［DP］”
“这样做的好处是不是说请求者不用管哪个对象来处理，反正该请求会被处理就对了？”
“是的，这就使得接收者和发送者都没有对方的明确信息，且链中的对象自己也并不知道链的结构。结果是职责链可简化对象的相互连接，它们仅需保持一个指向其后继者的引用，而不需保持它所有的候选接受者的引用［DP］。这也就大大降低了耦合度了。”
“我感觉由于是在客户端来定义链的结构，也就是说，我可以随时地增加或修改处理一个请求的结构。增强了给对象指派职责的灵活性［DP］。”
“是的，这的确是很灵活，不过也要当心，一个请求极有可能到了链的末端都得不到处理，或者因为没有正确配置而得不到处理，这就很糟糕了。需要事先考虑全面。”
“哈，这就跟现实中邮寄一封信，因地址不对，最终无法送达一样。”
“是的，就是这个意思。就刚才的例子而言，最重要的有两点，一个是你需要事先给每个具体管理者设置他的上司是哪个类，也就是设置后继者。另一点是你需要在每个具体管理者处理请求时，做出判断，是可以处理这个请求，还是必须要’推卸责任’，转移给后继者去处理。”
“哦，我明白你的意思了，其实就是把我现在写的这个管理者类当中的那些分支，分解到每一个具体的管理者类当中，然后利用事先设置的后继者来实现请求处理的权限问题。”
加薪代码重构
“是的，所以我们先来改造这个管理者类，此时它将成为抽象的父类了，其实它就是Handler。”
Request请求类与原来一样。
“经理类就可以去继承这个’管理者’类，只需重写’申请请求’的方法就可以了。”
“由于我们把你原来的一个’管理者’类改成了一个抽象类和三个具体类，此时类之间的灵活性就大大增加了，如果我们需要扩展新的管理者类别，只需要增加子类就可以。比如这个例子增加一个’集团总裁’类，完全是没有问题的，只需要修改’总经理类’即可，并不影响其他类代码。目前，还有一个关键，那就是客户端如何编写。”
结果显示：
“嗯，这的确是很好地解决了原来大量的分支判断造成难维护、灵活性差的问题。”
加薪成功
正在此时，小菜的手机响了起来。"喂，"小菜说，“李经理，您好。”
"小菜呀，是这样，我刚才又去找总经理了，向他也汇报了这一段时间你的工作情况，你的积极表现和非常优秀的编程能力总经理也是非常肯定的。所以他最终答应了你的申请，给你加薪，从下个月开始实施。"小菜的经理在电话那边说道。
"啊，是吗！真的谢谢您，万分感谢。回头我请您吃饭。嗯，好的，好的，OK，拜拜。"小菜脸上笑开了花。
“你这马屁精，干吗不跳槽了？不是说要跳的吗？”
“还跳什么槽呀。我这经理人真的不错，还专门去帮我找总经理谈，太为下属着想了。”
“哈，事实上，他是改变了职责链的结构，跳过了总监直接找总经理处理这事，这也体现了职责链灵活性的一个方面。”
"对的对的，设计模式真是无处不在呀。"小菜笑着说，“走，我请你吃炒面去。”
“谁说是炒面，我讲过的，我要吃的是——龙虾。”
如果对你有帮助，就一键三连呗（关注+点赞+收藏），我会持续更新更多干货~~
