状态模式-优雅的去除if/else

前言:用最简单的示例搞懂状态模式，请耐心看完…

---

现在有这么一个需求：
app要通过蓝牙给锁发送两条指令A和B,A和B都是我简化的说法,在执行A.B之前是会有其他的前置指令需要执行,比如E-R-A，Y-R-B,那么这两条指令首先都会经过一个R的响应,那么同样的响应如何区分是A指令的响应还是B指令的响应的呢？
1.0版本来了…
我的做法是通过一个boolean值来区分 伪代码如下:

boolean isA;
public void sendA(){
	...发送的逻辑
	isA = true;
}
public void sendB(){
...发送的逻辑
	isA = false;
}

public void onResponse(){
	if(isA){
		...执行A
	}else{
		...执行B
	}
}

很顺利的解决了问题…在指令执行前通过boolean值记录当前是哪条指令 在响应时做对应的判断

---

2.0版本来了…
现在的需求是增加两条指令C和D，同样他们都会经过R的响应那么上述的代码就需要改动了
我的做法是改动Boolean值为Int值

int type= -1;
int A = 1;
int B = 2;
int C = 3;
int D = 4;

public void sendA(){
...发送的逻辑
	type = A;
}
public void sendB(){
...发送的逻辑
	type = B;
}
public void sendB(){
...发送的逻辑
	type = C;
}

public void sendB(){
...发送的逻辑
	type =D;
}


public void onResponse(){
	if(type == A){
		...执行A
	}else if(type == B){
		...执行B
	}else if(type == C){
		...执行C
	}else if(type == D){
		...执行D
	}
}

问题解决了…但是自1.0开始我就觉得这种代码写出来不是我想要的,当业务逻辑复杂且多的情况下,整个类中充斥着大量的boolean值 和if else判断等,当搬砖的自己都觉得写出来的代码很烂的时候,应该就是要面临优化了…

---

重头戏来了,最近在看（Android源码设计模式解析与实战）一书时，看到状态模式时，顿时虎躯一震

---

3.0版本来了…在1.0的基础上进行优化尽量减少伪代码让大家看到更清晰

interface LockState{
	void parse();
}

class A implements LockState{
	void parse(){
		...执行A
	}
}

class B implements LockState{
	void parse(){
		...执行B
	}
}

public void sendA(LockState lockState){
	this.lockState = lockState;
	...发送的逻辑
}
public void sendB(LockState lockState){
	this.lockState = lockState;
	...发送的逻辑
}
public void onResponse(){
	lockState.parse();
}

问题解决了 当我发送A指令时 sendA(new A());发送B指令时 sendB(new B());而对应的A类和B类实现具体的业务.
这在最大程度上遵循了面向对象的六大原则
对于修改:是不需要做任何改动的
对于扩展:假设现在有E指令要添加只需要创建一个E类实现LockState就可以了
当然这只是我遇到的一个简单的示例,可以通过状态模式很优雅的解决(用策略模式同)…

---

套用Android源码设计模式解析与实战一书中对该模式的使用场景定义:

(1) 一个对象的行为取决于它的状态,并且它必须在运行时根据状态改变它的行为。
(2) 代码中包含大量与对象状态有关的条件语句,例如,一个操作中含有庞大的多分支语句 if-else或switch-case ),
且这些分支依赖于该对象的状态。状态模式将每一个条件分支放入一个独立的类中,这使得你可以根据对象自身的情况将对象的状态作为一个对象,这一对象可以不依赖于其他对象而独立变化,这样通过多态来去除过多的、重复的if-else等分支语句。

---

—写在最后的啰嗦—
这应该是2018年的最后一篇博文了…
过去的时间总觉得过的很快,未来的时间又总觉得还很长