小时候写日记都是这么写的:上午七点起床,八点以前洗脸刷牙吃早饭,十二点以前好好上课,中午一点,吃午餐,下午两点到六点,上课,下课,找请假,明天妈妈要带我去姥姥家,九点以前,看动画片,九点钟,收拾去姥姥家的东西,十点之后,睡觉。html
咱们把请假这块在充实一下:找班长请假,班长只能请半天,不然班长向老师申请,若是请假时间超过一周,老师要跟副年级主任请示,若是请假超出一个月,主任要跟年级正主任请示,而后被批准,或不被批准。编程
若是用编程语言描述这两件事情,应该是这个样子的。设计模式
- public class DayWork
- {
- private int hour;
-
-
- public void writeProgram()
- {
- if (hour < 7)
- {
- System.out.println("当前时间:" + hour + "点 睡觉");
- }
- else if (hour = 7)
- {
- System.out.println("当前时间:" + hour + "洗脸刷牙吃早饭");
- }
- else if (hour < 12)
- {
- System.out.println("当前时间:" + hour + "点 好好上课");
- }
- else if(hour=1)
- {
- System.out.println("当前时间:" + hour + "点 吃午餐");
-
- }
- else if(hour<18)
- {
- System.out.println("当前时间:" + hour + "点 好好学习");
-
- }
- }
-
- public int getHour()
- {
- return hour;
- }
-
- public void setHour(int hour)
- {
- this.hour = hour;
- }
-
-
- }
- //客户端代码
- public class Main
- {
- public static void main(String[] args)
- {
- DayWork work = new Work();
- work.setHour(9);
- work.writeProgram();
- work.setHour(10);
- work.writeProgram();
- work.setHour(12);
- work.writeProgram();
- work.setHour(13);
- work.writeProgram();
- work.setHour(14);
- work.writeProgram();
-
- }
- }
而请假的代码和这个差很少,if 请半天,班长请,else if 一周之内,老师请 else if 一个月之内 副主任请,else 超过一个月 主任请。app
但是,拿日记例子来看,过多的if分支并非一件好事,它首先不知足开闭原则,一旦须要修改整个IF语句都须要修改,责任没有费解,也不符合单一职责原则,咱们但愿分解整个行为,把状态的判断逻辑转移到表示不一样状态的一系列类当中,把复杂的判断逻辑简化,这就是咱们所说的状态模式。编程语言
状态模式结构图:
ide
状态模式代码实现:oop
- //State类,抽象状态类,定义一个接口以封装与Context的一个特定状态相关的行为
- public interface State
- {
- public void handle(Context context);
- }
- //ConcreteState类,具体状态,每个子类实现一个与Context的一个状态相关的行为。
- public class ConcreteStateA implements State
- {
- public void handle(Context context)
- {
- context.setState(new ConcreteStateB());
- }
- }
- public class ConcreteStateB implements State
- {
- public void handle(Context context)
- {
- context.setState(new ConcreteStateA());
- }
- }
- //Context类,维护一个ConcreteState子类的实例,这个实例定义当前的状态
- public class Context
- {
- private State state;
-
- public Context(State state)
- {
- this.state = state;
- }
-
- public void request()
- {
- state.handle(this);
- }
-
- public State getState()
- {
- return state;
- }
-
- public void setState(State state)
- {
- this.state = state;
- System.out.println("当前状态:" + state.getClass().getName());
- }
- }
- //客户端代码
- public class Main
- {
- public static void main(String[] args)
- {
- Context context = new Context(new ConcreteStateA());
-
- context.request();
- context.request();
- context.request();
- context.request();
- }
- }
状态模式将特定的状态相关的行为都放入一个对象中,因为全部与状态相关的代码都存在于某个ConcreteState中,因此经过定义新的子类能够很容易地增长新的状态和转换。学习
并且,状态模式把各类状态转移逻辑分布到State的子类之间,来减小相互间的依赖。动画
请假问题也是一个很复杂的条件表达式,安理说用状态模式是可使用的。this
可是,这里有一个问题,就是,若是班长请假了,用状态模式的道理讲,就是其余学生都请不了假了,也就是若是状态模式中任何一环缺失的话,这个事件都没法进行下去,怎么办?
这就须要咱们的职责链模式。
结构图:

代码实现:
- <pre name="code" class="html">// Chain of Responsibility pattern -- Structural example
- using System;
-
- // "Handler"
- abstract class Handler
- {
- // Fields
- protected Handler successor;
-
- // Methods
- public void SetSuccessor( Handler successor )
- {
- this.successor = successor;
- }
- abstract public void HandleRequest( int request );
- }
-
- // "ConcreteHandler1"
- class ConcreteHandler1 : Handler
- {
- // Methods
- override public void HandleRequest( int request )
- {
- if( request >= 0 && request < 10 )
- Console.WriteLine("{0} handled request {1}",
- this, request );
- else
- if( successor != null )
- successor.HandleRequest( request );
- }
- }
-
- // "ConcreteHandler2"
- class ConcreteHandler2 : Handler
- {
- // Methods
- override public void HandleRequest( int request )
- {
- if( request >= 10 && request < 20 )
- Console.WriteLine("{0} handled request {1}",
- this, request );
- else
- if( successor != null )
- successor.HandleRequest( request );
- }
- }
-
- // "ConcreteHandler3"
- class ConcreteHandler3 : Handler
- {
- // Methods
- override public void HandleRequest( int request )
- {
- if( request >= 20 && request < 30 )
- Console.WriteLine("{0} handled request {1}",
- this, request );
- else
- if( successor != null )
- successor.HandleRequest( request );
- }
- }
-
- /**//// <summary>
- /// Client test
- /// </summary>
- public class Client
- {
- public static void Main( string[] args )
- {
- // Setup Chain of Responsibility
- Handler h1 = new ConcreteHandler1();
- Handler h2 = new ConcreteHandler2();
- Handler h3 = new ConcreteHandler3();
- h1.SetSuccessor(h2);
- h2.SetSuccessor(h3);
-
- // Generate and process request
- int[] requests = { 2, 5, 14, 22, 18, 3, 27, 20 };
-
- foreach( int request in requests )
- h1.HandleRequest( request );
-
- }
- }
职责链模式(Chain of Responsibility):使多个对象都有机会处理请求,从而避免请求的发送者和接受者之间的耦合关系。将这个对象练成一条链,并沿着这条链传递该请求,直到有一个对象处理它为止。
从代码中咱们能够看出,职责链模式的链式在客户端链接的,也就是说,若是咱们请假,请假制度一旦改变,好比说咱们不须要班长,或者是先请求老师后直接请求主任或者中间多了一个环节,都是很容易实现的,因此,职责链模式要比状态模式灵活不少。
可是,这时候是否是有人要问,均可以解决If分支过多,是否是职责链模式比状态模式好呢,仍是那句话,存在即合理,职责链模式虽然灵活,可是他过于灵活,咱们在使用时须要肯定下一个对象是谁,在屡次设置的时候很容易出问题,因此,这时候用状态模式就比较好,就像咱们记录一天的行为,事情已经发生,若是用职责链模式就显得多此一举了。
从定义来看,状态模式是一个对象的内在状态发生改变(一个对象,相对比较稳定,处理完一个对象下一个对象的处理通常都已肯定),而职责链模式是多个对象之间的改变(多个对象之间的话,就会出现某个对象不存在的如今,就像请假例子中的班长或者老师可能缺勤),这也说明他们两个模式处理的状况不一样。
其实,这两个设计模式最大的区别就是状态模式是让各个状态对象本身知道其下一个处理的对象是谁,即在编译时便设定好了的;
而职责链模式中的各个对象并不指定其下一个处理的对象究竟是谁,只有在客户端才设定。用咱们通俗的编程语言来讲,就是
状态模式:
至关于If else if else;
设计路线:各个State类的内部实现(至关于If,else If内的条件)
执行时经过State调用Context方法来执行。
职责链模式:
至关于Swich case
设计路线:客户设定,每一个子类(case)的参数是下一个子类(case)。
使用时,向链的第一个子类的执行方法传递参数就能够。
就像对设计模式的总结,有的人采用的是状态模式,从头至尾,提早必定定义好下一个处理的对象是谁,而我采用的是职责链模式,随时都有可能调整链的顺序