我们每天都在乘电梯,那我们来看看电梯有哪些动作(映射到 Java 中就是有多少方法):开门、关门、运行、停止,就这四个动作,好,我们就用程序来实现一下电梯的动作,先看类图设计:
代码如下:
代码语言:javascript复制/**
* @description 定义一个电梯的接口
*/
public interface ILift {
/**
* 电梯门开启动作
*/
void open();
/**
* 电梯门关闭动作
*/
void close();
/**
* 电梯上升或下降
*/
void run();
/**
* 电梯停在某层
*/
void stop();
}
public class Lift implements ILift {
@Override
public void open() {
System.out.println("电梯门打开...");
}
@Override
public void close() {
System.out.println("电梯门关闭...");
}
@Override
public void run() {
System.out.println("电梯上升或下降...");
}
@Override
public void stop() {
System.out.println("电梯停在某层...");
}
}
public class Client {
public static void main(String[] args) {
ILift lift = new Lift();
lift.open();
lift.close();
lift.run();
lift.stop();
}
}
这个程序有什么问题,你想呀电梯门可以打开,但不是随时都可以开,是有前提条件的的,你不可能电梯在运行的时候突然开门吧?!电梯也不会出现停止了但是不开门的情况吧?!电梯的这四个动作的执行都是有前置条件,具体点说在特定状态下才能做特定事,那我们来分析一下电梯有什么那些特定状态:
- 门敞状态:按了电梯上下按钮,电梯门开,这中间有5秒的时间,在这个状态下电梯只能做的动作是关门动作,做别的动作那就危险
- 门闭状态:电梯门关闭了,在这个状态下,可以进行的动作是:开门(我不想坐电梯了)、停止(忘记按楼层号了)、运行
- 运行状态:电梯正在跑,上下窜,在这个状态下,电梯只能做的是停止;
- 停止状态:电梯停止不动,在这个状态下,电梯有两个可选动作:继续运行或者开门;
我们用一张表来表示电梯状态和动作之间的关系:
好,我们来修改一下,先看类图:
在接口中定义了四个常量,分别表示电梯的四个状态:门敞状态、关闭状态、运行状态、停止状态,然后在实现类中电梯的每一次动作发生都要对状态进行判断,判断是否运行执行,也就是动作的执行是否符合业务逻辑,实现类中的四个私有方法是仅仅实现电梯的动作,没有任何的前置条件,因此这四个方法是不能为外部类调用的,设置为私有方法。代码如下:
代码语言:javascript复制public interface ILift {
/**
* 门敞状态
*/
int OPENING_STATE = 1;
/**
* 门闭状态
*/
int CLOSING_STATE = 2;
/**
* 运行状态
*/
int RUNNING_STATE = 3;
/**
* 设置电梯的状态
* @param state 电梯状态
*/
void setState(int state);
/**
* 停止状态
*/
int STOPPING_STATE = 4;
/**
* 电梯门开启动作
*/
void open();
/**
* 电梯门关闭动作
*/
void close();
/**
* 电梯上升或下降
*/
void run();
/**
* 电梯停在某层
*/
void stop();
}
public class Lift implements ILift {
private int state;
@Override
public void setState(int state) {
this.state = state;
}
@Override
public void open() {
// 在关门状态和停止状态可以开门,其他状态什么也不做
switch (state) {
case CLOSING_STATE:
case STOPPING_STATE:
openWithoutLogic();
setState(OPENING_STATE);
break;
case OPENING_STATE:
case RUNNING_STATE:
// do nothing
break;
default: // do nothing
}
}
@Override
public void close() {
// 只有在开门状态可以关门
switch (state) {
case OPENING_STATE:
closeWithoutLogic();
setState(CLOSING_STATE);
break;
case CLOSING_STATE:
case STOPPING_STATE:
case RUNNING_STATE:
// do nothing
break;
default: // do nothing
}
}
@Override
public void run() {
// 只有在关闭状态和停止状态可以运行
switch (state) {
case CLOSING_STATE:
case STOPPING_STATE:
runWithoutLogic();
setState(RUNNING_STATE);
break;
case OPENING_STATE:
case RUNNING_STATE:
// do nothing
break;
default: // do nothing
}
}
@Override
public void stop() {
// 只有在关闭状态和运行状态可以停止
switch (state) {
case CLOSING_STATE:
case RUNNING_STATE:
stopWithoutLogic();
setState(STOPPING_STATE);
break;
case OPENING_STATE:
case STOPPING_STATE:
// do nothing
break;
default: // do nothing
}
}
/**
* 单纯的打开门,不考虑其他条件
*/
private void openWithoutLogic() {
System.out.println("电梯门打开...");
}
/**
* 单纯的关闭门,不考虑其他条件
*/
private void closeWithoutLogic() {
System.out.println("电梯门关闭...");
}
/**
* 单纯的运行,不考虑其他条件
*/
private void runWithoutLogic() {
System.out.println("电梯上升或下降...");
}
/**
* 单纯的停止,不考虑其他条件
*/
private void stopWithoutLogic() {
System.out.println("电梯停在某层...");
}
}
public class Client {
public static void main(String[] args) {
ILift lift = new Lift();
// 电梯的初始状态为停止状态
lift.setState(ILift.STOPPING_STATE);
lift.open();
lift.close();
lift.run();
lift.stop();
}
}
以上的代码也是有问题的:
- 首先
Lift
这个类有点长,长的原因是我们在程序中使用了大量的switch…case
这样的判断(if…else
也是一样),程序中只要你有这样的判断就避免不了加长程序,同步的在业务比较复杂的情况下,程序体会更长,这个就不是一个很好的习惯了,较长的方法或者 类的维护性比较差 - 其次,扩展性非常的不好,大家来想想,电梯还有两个状态没有加,是什么?通电状态和断电状态,你要是在程序再增加这两个方法,你看看
open()
、close()
、run()
、stop()
这四个方法都要增加判断条件,也就是说switch
断体中还要增加case
项,也就说与开闭原则相违背了; - 再其次,我们来思考我们的业务,电梯在门敞开状态下就不能上下跑了吗?电梯有没有发生过只有运行没有停止状态呢(从 40 层直接坠到 1 层嘛)?电梯故障,还有电梯在检修的时候,可以在
stop
状态下不开门,这也是正常的业务需求呀,你想想看,如果加上这些判断条件,上面的程序有多少需要修改?看看我们的类,业务上的任务一个小小增加或改动都对我们的这个电梯类产生了修改,这是在项目开发上是有很大风险的
我们来思考两个问题:
- 第一、这个停止状态时怎么来的,那当然是由于电梯执行了
stop()
方法而来的; - 第二、在停止状态下,电梯还能做什么动作?继续运行?开门?那当然都可以了。
我们再来分析其他三个状态,也都是一样的结果,我们只要实现电梯在一个状态下的两个任务模型就可以了:这个状态是如何产生的以及在这个状态下还能做什么其他动作(也就是这个状态怎么过渡到其他状态),既然我们以状态为参考模型,那我们就先定义电梯的状态接口,思考过后我们来看类图:
在类图中,定义了一个LiftState
抽象类,声明了一个受保护的类型Context
变量,这个是串联我们各个状态的封装类,封装的目的很明显,就是电梯对象内部状态的变化不被调用类知晓,也就是迪米特法则了,我的类内部情节你知道越少越好,并且还定义了四个具体的实现类,承担的是状态的产生以及状态间的转换过渡,全部的代码如下:
public abstract class LiftState {
/**
* 定义一个环境角色,也就是封装状态的变换引起的功能变化
*/
protected Context context;
public void setContext(Context context) {
this.context = context;
}
/**
* 电梯门开启动作
*/
public abstract void open();
/**
* 电梯门关闭动作
*/
public abstract void close();
/**
* 电梯运行动作
*/
public abstract void run();
/**
* 电梯停止动作
*/
public abstract void stop();
}
public class Context {
/**
* 定义出所有的电梯状态
*/
public static final OpeningState OPENING_STATE = new OpeningState();
public static final ClosingState CLOSING_STATE = new ClosingState();
public static final RunningState RUNNING_STATE = new RunningState();
public static final StoppingState STOPPING_STATE = new StoppingState();
/**
* 定义一个当前电梯状态
*/
private LiftState liftState;
public LiftState getLiftState() {
return liftState;
}
public void setLiftState(LiftState liftState) {
this.liftState = liftState;
// 把当前环境通知到各个实现类中
this.liftState.setContext(this);
}
public void open() {
liftState.open();
}
public void close() {
liftState.close();
}
public void run() {
liftState.run();
}
public void stop() {
liftState.stop();
}
}
public class OpeningState extends LiftState {
@Override
public void open() {
System.out.println("电梯门开启...");
}
@Override
public void close() {
// 修改状态
super.context.setLiftState(Context.CLOSING_STATE);
// 动作委托CLOSING_STATE来执行
super.context.getLiftState().close();
}
/**
* 打开状态不能运行
*/
@Override
public void run() {
// do nothing
}
/**
* 打开状态是停止状态
*/
@Override
public void stop() {
// do nothing
}
}
public class ClosingState extends LiftState {
@Override
public void open() {
super.context.setLiftState(Context.OPENING_STATE);
super.context.getLiftState().open();
}
@Override
public void close() {
System.out.println("电梯门关闭...");
}
@Override
public void run() {
super.context.setLiftState(Context.RUNNING_STATE);
super.context.getLiftState().run();
}
@Override
public void stop() {
super.context.setLiftState(Context.STOPPING_STATE);
super.context.getLiftState().stop();
}
}
public class RunningState extends LiftState {
@Override
public void open() {
// do nothing
}
@Override
public void close() {
// do nothing
}
@Override
public void run() {
System.out.println("电梯上下跑...");
}
@Override
public void stop() {
super.context.setLiftState(Context.STOPPING_STATE);
super.context.getLiftState().stop();
}
}
public class StoppingState extends LiftState {
@Override
public void open() {
super.context.setLiftState(Context.OPENING_STATE);
super.context.getLiftState().open();
}
@Override
public void close() {
// do nothing
}
@Override
public void run() {
super.context.setLiftState(Context.RUNNING_STATE);
super.context.getLiftState().run();
}
@Override
public void stop() {
System.out.println("电梯停止了...");
}
}
public class Client {
public static void main(String[] args) {
Context context = new Context();
context.setLiftState(new ClosingState());
context.open();
context.close();
context.run();
context.stop();
}
}
我们可以这样理解,Context
是一个环境角色,它的作用是串联各个状态的过渡,在LiftSate
抽象类中我们定义了并把这个环境角色聚合进来,并传递到了子类,也就是四个具体的实现类中自己根据环境来决定如何进行状态的过渡。
我们再来回顾一下我们刚刚批判上一段的代码,首先我们说人家代码太长,这个问题我们解决了,通过各个子类来实现,每个子类的代码都很短,而且也取消了的switch…case
条件的判断;
其次,说人家不符合开闭原则,那如果在我们这个例子中要增加两个状态怎么加?增加两个子类,一个是通电状态,一个是断电状态,同时修改其他实现类的相应方法,因为状态要过渡呀,那当然要修改原有的类,只是在原有类中的方法上增加,而不去做修改;
再其次,我们说人家不符合迪米特法则,我们现在呢是各个状态是单独的一个类,只有与这个状态的有关的因素修改了这个类才修改,符合迪米特法则,非常完美!
上面例子中多次提到状态,那我们这节讲的就是状态模式,什么是状态模式呢?当一个对象内在状态改变时允许其改变行为,这个对象看起来像是改变了其类。说实话,这个定义的后半句我也没看懂,看过GOF才明白是怎么回事: Allow an object to alter its behavior when its internal state changes. The object will appear to change its class
,也就是说状态模式封装的非常好,状态的变更引起了行为的变更,从外部看起来就好像这个对象对应的类发生了改变一样。
状态模式的通用实现类如下:
状态模式中有什么优点呢?
- 首先是避免了过多的
swith…case
或者if...else
语句的使用,避免了程序的复杂性; - 其次是很好的使用体现了开闭原则和单一职责原则,每个状态都是一个子类,你要增加状态就增加子类,你要修改状态,你只修改一个子类就可以了;
- 最后一个好处就是封装性非常好,这也是状态模式的基本要求,状态变换放置到了类的内部来实现,外部的调用不用知道类内部如何实现状态和行为的变换。
状态模式的缺点:类会太多,也就是类膨胀,一个事物有七八十来个状态也不稀奇,如果完全使用状态模式就会有太多的子类,不好管理。
状态模式使用于当某个对象在它的状态发生改变时,它的行为也随着发生比较大的变化,也就是说行为是受状态约束的情况下可以使用状态模式,而且状态模式使用时对象的状态最好不要超过五个。
本文原书:
《您的设计模式》 作者:CBF4LIFE