前言:用最简单的示例搞懂状态模式,请耐心看完…
现在有这么一个需求:
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年的最后一篇博文了…
过去的时间总觉得过的很快,未来的时间又总觉得还很长