菜鸟工作满三个月了，马上要办转正首先，提了加薪的事情。菜鸟对经理如实说了自己的想法，希望公司能在转正时增加工资待遇，经理肯定了菜鸟的能力，但是加薪做不了主，但是帮他向上提一提。然后去找了人力资源总监，总监说这事他也做不了主，毕竟刚毕业的大学生加薪没有先例，但总监说，等总经理来后，向总经理提一提这个事。最后，从经理那里得到的消息是，总经理不同意加薪，因为现在大学毕业生这么多，随便都能找得到，三个月就想加薪，不合适。
一、加薪代码初步
无论加薪还是请假，都是一种申请。申请就应该有申请类别、申请内容和申请数量。
经理、总监、总经理都是管理者，他们在对‘申请’处理时，需要做出判断，是否有权决策
“管理者”类，里面的‘结果’方法比较长，加上有太多的分支判断，者其实是非常不好的设计。因为你很难讲当中还会不会增加其他的管理类别，比如项目经理、部门经理、人力总监、副总经理等等。哪就意味着都需要去更改这个类，这个类承担了太多的责任，者违背了单一职责原则，增加新的管理类别，需要修改这个类，违背了开放-封闭原则。
应该如何下手去重构它呢？
可能会增加管理类别，那就意味着这里容易变化，应该把这些公司管理者的类别做成管理者的子类，者就可以利用多态性来化解分支带来的僵化。
那如何解决经理无权上报总监，总监无权再上报总经理这样的功能呢？
它们之间有一定的关联，把用户的请求传递，知道可以解决这个请求为止。这就是‘职责链模式’的意图了。
二、职责链模式
职责链模式（Chain of Responsibility）:使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这个对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。
这里发出这个请求的客户端并不知道这当中的哪一个对象最终处理这个请求，这样系统的更改可以在不影响客户端的情况下动态地重新组织和分配责任。
三、职责链的好处
当客户提交一个请求时，请求是沿链传递直至有一个ConcreteHandler对象负责处理它。
这样做的好处是请求者不用管哪个对象来处理，反正该请求会被处理就对了。
接收者和发送者都没有对方的明确信息，且链中的对象自己也并不知道链的结构。结果是职责链可简化对象的相互连接，它们仅需保持一个指向其后继者的引用，而不需保持它所有的候选接受者的引用。这也就大大降低了耦合度了。
随时地增加或修改处理一个请求的结构。增强了给对象指派职责的灵活性。
一个请求极有可能到了链的末端都得不到处理，或者因为没有正确配置而得不到处理，者就很糟糕了。
对于刚才的例子，最重要的有亮点，一个是你需要事先给每个具体管理者设置他的上司是哪个类，也就是设置后继者。另一点是你需要在每个具体管理者处理请求时，做出判断，是可以处理这个请求，还是必须要‘推卸责任’，转移给后继者去处理。
其实就是把现在写的这个管理者类当中的那些分支，分解到每一个具体的管理者类当中，然后利用事先设置的后继者类实现请求处理的权限问题。
四、加薪代码重构
这的确是很好地解决了原来大量的分支判断造成难以维护、灵活性差的问题。