对于状态模式,我感觉就像是父类和子类之间的多态,通过状态接口新建不同的状态实现类,然后通过状态的不同调用不同的方法,如此而已。
网络上的专业解释: 此模式中,类的行为是基于他的状态改变的,此模式中,对象的行为依赖于他的状态,并且可根据他状态的改变而改变它的相关行为。
实例:用此模式描述消极状态和积极模式的人。
以下是我根据此实例画出的类图:
以下是我编写的代码:
1.编写状态接口,其中可以有多个方法用于对应每一个状态的反应
//状态接口
interface State {
//不同状态所要实现的方法
void doSomething();
}
2.编写状态的对个实现类,来实现其中的方法以做出不同的应对
public class ActiveState implements State{
@Override
public void doSomething() {
System.out.println("积极状态......");
}
}
public class NegativeState implements State{
@Override
public void doSomething() {
System.out.println("消极状态......");
}
}
3.创建一个状态的作用类,来调用每次的状态中实现的方法
public class Person {
//默认为积极状态
private State as=new ActiveState();
public void setAs(State as) {
this.as = as;
}
public void doSomething(){
as.doSomething();
}
}
4.编写测试类,用于测试作用类是否可以正常更换状态
public class Test {
public static void main(String[] args) {
Person p =new Person();
System.out.println("========默认状态========");
p.doSomething();
System.out.println("========改变状态========");
p.setAs(new NegativeState());
p.doSomething();
}
}
5.后台输出:
========默认状态========
积极状态......
========改变状态========
消极状态......
对于此模式的优点:
1.此模式把不同的状态所对应的不同行为封装到了不同的类中,隐藏了各个状态对应行为的细节。
2.要加别的状态时,只需要实现状态接口即可,这一点符合”开闭原则”。
3.由于状态类与状态作用类实现的是松耦合,所以,其他的状态作用类可以共享已经完成的状态类,实现了代码共享。
缺点:
1.用此模式会增加类和对象的个数,就是状态类造成的。
2.用此模式的时候要列举所有的状态,并且列举前要确定状态的具体实现类,状态少的话还好说,太多的话就会提高编码的复杂度了。
3.如果要为某一个状态再添加别的行为的话,或者为状态作用类添加别的方法的话,都要修改代码的,扩展不了,从这一点来说又与优点的第3点相悖,违反了”开闭原则”。