小谈设计模式(17)—状态模式

简介: 小谈设计模式(17)—状态模式

专栏介绍

专栏地址

link

专栏介绍

主要对目前市面上常见的23种设计模式进行逐一分析和总结,希望有兴趣的小伙伴们可以看一下,会持续更新的。希望各位可以监督我,我们一起学习进步,加油,各位。


状态模式

状态模式是一种行为型设计模式,它允许一个对象在内部状态发生变化时改变其行为。状态模式将对象的行为封装在不同的状态类中,通过改变对象的状态来改变其行为。

关键角色

上下文(Context)

上下文是一个包含状态的对象,它定义了客户端与状态对象的交互接口。上下文中维护了一个指向当前状态的引用,并且在运行时可以切换到不同的状态。上下文将客户端请求委派给当前状态对象处理。

抽象状态(State)

抽象状态是一个接口或抽象类,它定义了状态对象的通用行为。具体状态类需要实现这个接口或继承这个抽象类,并且根据具体的状态来实现相应的行为。

具体状态(Concrete State)

具体状态是实现抽象状态的具体类。每个具体状态类都代表了上下文在特定状态下的行为。具体状态类负责处理上下文的请求,并在需要时切换到其他状态。

核心思想

将状态的判断和状态的行为分离,使得状态的变化不影响行为的变化。通过将状态的行为封装在具体状态类中,可以方便地添加新的状态或修改现有状态的行为,同时也避免了状态判断的复杂性。

Java程序实现

首先,我们定义一个抽象状态类 State,其中包含一个处理请求的方法 handleRequest():

public abstract class State {
    public abstract void handleRequest();
}

然后,我们创建两个具体状态类 ConcreteStateA 和 ConcreteStateB,它们分别实现了抽象状态类 State:

public class ConcreteStateA extends State {
    @Override
    public void handleRequest() {
        System.out.println("处理请求,当前状态为A");
    }
}

public class ConcreteStateB extends State {
    @Override
    public void handleRequest() {
        System.out.println("处理请求,当前状态为B");
    }
}

接下来,我们创建一个上下文类 Context,其中包含一个指向当前状态的引用,并提供了一个方法 setState() 用于切换状态和一个方法 request() 用于处理请求:

public class Context {
    private State currentState;

    public Context() {
        // 初始化为初始状态
        currentState = new ConcreteStateA();
    }

    public void setState(State state) {
        currentState = state;
    }

    public void request() {
        currentState.handleRequest();
    }
}

最后,我们可以在客户端代码中使用上下文类来测试状态模式的效果:

public class Client {
    public static void main(String[] args) {
        Context context = new Context();

        // 处理请求,当前状态为A
        context.request();

        // 切换状态为B
        context.setState(new ConcreteStateB());

        // 处理请求,当前状态为B
        context.request();
    }
}

输出结果

处理请求,当前状态为A
处理请求,当前状态为B

分析

在上述示例中,我们通过状态模式实现了一个简单的上下文对象 Context,它可以根据不同的状态来处理请求。通过切换状态,上下文对象可以改变其行为。这样,我们可以方便地添加新的状态类或修改现有状态的行为,而不需要修改客户端代码。

优缺点分析

优点

1

通过将状态的行为封装在具体状态类中,可以使得状态的变化对客户端透明,客户端只需要与上下文进行交互,不需要关心具体的状态。

2

增加新的状态类相对容易,符合开闭原则,不需要修改现有的代码。

3

将状态的行为集中到具体状态类中,使得代码更加清晰,易于维护和扩展。

缺点

1

当状态的行为比较少或简单时,使用状态模式可能会导致类的数量增加,增加了代码的复杂性。

2

如果状态之间存在相互转换的复杂逻辑,可能需要引入其他模式来处理状态之间的转换。

总结

状态模式是一种通过将状态的行为封装在具体状态类中,使得状态的变化不影响行为的设计模式。它可以使代码更加清晰、易于维护和扩展,适用于状态变化较多且状态之间的行为差异较大的场景。

相关文章
|
6月前
|
设计模式
设计模式之 State(状态模式)
设计模式之 State(状态模式)
42 0
|
2月前
|
设计模式 Java 测试技术
Java设计模式-状态模式(18)
Java设计模式-状态模式(18)
|
3月前
|
设计模式 网络协议 Java
【十五】设计模式~~~行为型模式~~~状态模式(Java)
文章详细介绍了状态模式(State Pattern),这是一种对象行为型模式,用于处理对象在其内部状态改变时的行为变化。文中通过案例分析,如银行账户状态管理和屏幕放大镜工具,展示了状态模式的应用场景和设计方法。文章阐述了状态模式的动机、定义、结构、优点、缺点以及适用情况,并提供了Java代码实现和测试结果。状态模式通过将对象的状态和行为封装在独立的状态类中,提高了系统的可扩展性和可维护性。
【十五】设计模式~~~行为型模式~~~状态模式(Java)
|
4月前
|
设计模式 JavaScript Go
js设计模式【详解】—— 状态模式
js设计模式【详解】—— 状态模式
80 7
|
5月前
|
设计模式
状态模式-大话设计模式
状态模式-大话设计模式
|
5月前
|
设计模式 存储
行为设计模式之状态模式
行为设计模式之状态模式
|
6月前
|
设计模式 Go
[设计模式 Go实现] 行为型~状态模式
[设计模式 Go实现] 行为型~状态模式
|
6月前
|
设计模式 Java
23种设计模式,状态模式的概念优缺点以及JAVA代码举例
【4月更文挑战第9天】状态模式是一种行为设计模式,允许一个对象在其内部状态改变时改变它的行为,这个对象看起来似乎修改了它的类。
58 4
|
6月前
|
设计模式 JavaScript Java
[设计模式Java实现附plantuml源码~行为型] 对象状态及其转换——状态模式
[设计模式Java实现附plantuml源码~行为型] 对象状态及其转换——状态模式
|
6月前
|
设计模式 Java
【设计模式系列笔记】状态模式
在Java中,状态模式是一种行为设计模式,它允许对象在其内部状态改变时改变其行为。状态模式的关键思想是将对象的状态封装成独立的类,并将对象的行为委托给当前状态的对象。这样,当对象的状态发生变化时,其行为也会相应地发生变化。
68 0

热门文章

最新文章

  • 1
    C++一分钟之-设计模式:工厂模式与抽象工厂
    43
  • 2
    《手把手教你》系列基础篇(九十四)-java+ selenium自动化测试-框架设计基础-POM设计模式实现-下篇(详解教程)
    46
  • 3
    C++一分钟之-C++中的设计模式:单例模式
    54
  • 4
    《手把手教你》系列基础篇(九十三)-java+ selenium自动化测试-框架设计基础-POM设计模式实现-上篇(详解教程)
    38
  • 5
    《手把手教你》系列基础篇(九十二)-java+ selenium自动化测试-框架设计基础-POM设计模式简介(详解教程)
    62
  • 6
    Java面试题:结合设计模式与并发工具包实现高效缓存;多线程与内存管理优化实践;并发框架与设计模式在复杂系统中的应用
    57
  • 7
    Java面试题:设计模式在并发编程中的创新应用,Java内存管理与多线程工具类的综合应用,Java并发工具包与并发框架的创新应用
    41
  • 8
    Java面试题:如何使用设计模式优化多线程环境下的资源管理?Java内存模型与并发工具类的协同工作,描述ForkJoinPool的工作机制,并解释其在并行计算中的优势。如何根据任务特性调整线程池参数
    50
  • 9
    Java面试题:请列举三种常用的设计模式,并分别给出在Java中的应用场景?请分析Java内存管理中的主要问题,并提出相应的优化策略?请简述Java多线程编程中的常见问题,并给出解决方案
    106
  • 10
    Java面试题:设计模式如单例模式、工厂模式、观察者模式等在多线程环境下线程安全问题,Java内存模型定义了线程如何与内存交互,包括原子性、可见性、有序性,并发框架提供了更高层次的并发任务处理能力
    78