我的java设计模式 总结【15】状态模式 State & 解释器 Intepreter

State 状态模式

这个也不难，就是根据状态决定行为。简单来说，就是类里面的方法都要判断当前状态，才能知道该如何运行的时候，将这些需要判断状态的方法抽象出来根据不同的状态获取不同的实现来进行执行方法。
例举一个原始的方式：

public class Old {
	int state;
	public Old(int s) {
		state = s;
	}
	public void method1() {
		switch (state) {
		case 1:
			System.out.println("hello m11");
			break;
		case 2:
			System.out.println("hello m12");
			break;
		case 3:
			System.out.println("hello m13");
			break;
		}
	}
	public void method2() {
		switch (state) {
		case 1:
			System.out.println("hello m21");
			break;
		case 2:
			System.out.println("hello m22");
			break;
		case 3:
			System.out.println("hello m23");
			break;
		}
	}

	public void method3() {
		switch (state) {
		case 1:
			System.out.println("hello m31");
			break;
		case 2:
			System.out.println("hello m32");
			break;
		case 3:
			System.out.println("hello m33");
			break;
		}
	}
}

这个类只是简单的表达了一下问题。state的状态。和类中method1,method2，method3的switch 。
对于类似这种问题。就需要将state状态的判断进行解耦和拆分了。
根据state模式修改以后会是

abstract class M {
	abstract void method1();

	abstract void method2();

	abstract void method3();
}

class M1 extends M {
	@Override
	void method1() {
		System.out.println("hello m11");
	}
	@Override
	void method2() {
		System.out.println("hello m12");
	}
	@Override
	void method3() {
		System.out.println("hello m13");
	}
}
class M2 extends M {
	@Override
	void method1() {
		System.out.println("hello m21");
	}
	@Override
	void method2() {
		System.out.println("hello m22");
	}
	@Override
	void method3() {
		System.out.println("hello m23");
	}
}

class M3 extends M {
	@Override
	void method1() {
		System.out.println("hello m31");
	}
	@Override
	void method2() {
		System.out.println("hello m32");
	}
	@Override
	void method3() {
		System.out.println("hello m33");
	}
}

public class New {

	int state;

	public New(int s) {
		state = s;
	}

	public void dostate() {
		M m=null;
		switch (state) {
		case 1:
			m=new M1();
			break;
		case 2:
			m=new M2();
			break;
		case 3:
			m=new M3();
			break;
		}
		m.method1();
		m.method2();
		m.method3();
	}
}

对此来说。可以很明显了的知道了。不同M实现类只需要关注自己的本身实现就好了。也无需判断。而判断交给调用这来判断具体采用什么状态类型的实现类即可。

需要注意的是

从不同的维度来分析。

• 当你的方法需要不断的进行扩展的时候是不适合用state模式的。比如上面的例子我需要增加一个method4的话所有子类都需要再重写一次method4，这样非常的不方便，反而适得其反。反之就是当method不会再扩展的时候可以考虑适用state模式。
• 再者当你的state不会扩展，状态为固定的时候那不如就用switch来判断。省了写那么多的子类。比如上面的例子我就123三种状态，不会再出现其他状态的时候那么初始的那个例子是完全可以的。不需要写那么多的子类实现
• 总之state就是适合用于方法不增加，但是状态会不断增加的那种案例，当其中一条都不满足的时候就需要多考虑。总之以实际为主。

解释器 Intepreter

解释器模式，其实类似于解释模式。类似是在一种语言上在做一种语言的解释器。比如用C开发的python解析器。用C开发的java解析器。等等。我从业以来没用过。只当知道一下而已。具体信息百度其他大神资料。