AI Chat 设计模式:11. 状态模式

这篇具有很好参考价值的文章主要介绍了AI Chat 设计模式:11. 状态模式。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

本文是该系列的第十一篇,采用问答式的方式展开,问题由我提出,答案由 Chat AI 作出,灰色背景的文字则主要是我的一些思考和补充。

Q.1 你知道状态模式吗

A.1

是的,我知道状态模式。状态模式是一种行为设计模式,它允许对象在不同的内部状态下改变其行为。在状态模式中,对象的行为取决于其状态,并且可以在运行时更改对象的状态。

状态模式包括三个主要角色:上下文(Context)、状态接口(State)和具体状态(Concrete State)。上下文是包含状态的对象,并将请求委派给当前状态处理。状态接口定义了所有具体状态必须实现的方法。具体状态是实现状态接口的具体类,每个具体状态负责处理特定的请求。

使用状态模式可以实现将复杂的条件语句转换为清晰的状态类,提高代码的可维护性和可扩展性。状态模式常用于需要根据对象内部状态改变行为的情况,例如状态机、游戏状态管理等。

Q.2 它与有限状态机有什么联系吗?

A.2

状态模式和有限状态机(FSM,Finite State Machine)之间存在一定联系,但它们是不同的概念。

有限状态机是一种数学模型,用于描述对象、系统或者程序的状态以及状态之间的转换。它由一组状态事件转移条件组成,当满足特定的条件时,会发生状态之间的转移。有限状态机可以是确定的(确定性有限状态机)或者非确定的(非确定性有限状态机),并可以用于解决不同的问题,如自动控制、编译器设计等。

而状态模式是一种软件设计模式,它用于将对象的行为与其内部状态相关联。对象在不同的状态下可以具有不同的行为,而状态模式允许对象在运行时根据状态的变化而改变其行为。与有限状态机不同,状态模式更关注对象的内部状态和行为之间的关系。

尽管状态模式和有限状态机都涉及到状态和状态之间的转换,但它们的关注点和应用领域有所不同。状态模式更加注重对象的内部行为和状态之间的关系,而有限状态机更关注的是问题的建模和状态转换过程。

一般认为状态模式是状态机的一种实现方式。

状态机由状态事件动作三部分组成。事件是触发状态转移的条件或原因,动作是进入该状态后产生的行为。当事件发生时,会根据当前状态作出动作,然后进入下一状态。
我们简单举一个倒霉大学生的例子,以毕业了为初始状态,“找到工作了”这一事件发生后,他会进入“兴奋”状态,此时他可能会产生“吃顿好的”这个动作(图里并未画出);有一天发生了“被老板骂”这一事件,他进入了“低落状态”,在该状态下会作出什么动作呢?忍了,或者硬刚,或者啥也不做(状态转换后,不一定有动作发生);过了一阵子,他被炒了,“失业”这一事件导致他进入了“沮丧”状态;再后来,“老婆跑了”,这一事件直接让他进入了“绝望”状态;然后又发生了一些事,这个大学生进入了“无”的状态。
如果想更多了解状态机,就需要去专门学习一下相关文章了,这里只是简单介绍。
AI Chat 设计模式:11. 状态模式,设计模式,设计模式,c++,Chat AI,状态模式

Q.3 知道了,我是第一次学习状态模式,你能由浅入深给我讲解一下吗

A.3

当然可以!我可以帮你由浅入深地理解状态模式。

状态模式的核心思想是将对象的行为和状态分离,通过定义不同的状态类来管理对象的状态并实现相应的行为。这使得对象的行为可以根据状态的变化而灵活改变,同时也减少了大量的条件语句,提高了代码的可读性和可维护性。

让我们以一个简单的示例来说明状态模式的使用。

假设我们要设计一个电梯系统,其中电梯可以处于三种状态:关闭状态开启状态运行状态。不同状态下,电梯的行为是不同的。

首先,我们创建一个状态接口(State),该接口定义了所有具体状态类必须实现的方法,比如opencloserun等方法。

public interface State {
    void open();
    void close();
    void run();
}

open()、close()、run() 这三个方法,定义了电梯的三个行为,同时也是我们前面提到的状态转移条件(事件)。

然后,我们创建具体的状态类,分别是OpenStateCloseStateRunState,它们实现了状态接口,负责实现对应状态下的行为。

public class OpenState implements State {
    @Override
    public void open() {
        System.out.println("电梯已经是开启状态,无需再次开门");
    }

    @Override
    public void close() {
        System.out.println("电梯关闭门");
        // 切换到关闭状态
        context.setState(new CloseState());
    }

    @Override
    public void run() {
        System.out.println("电梯正在运行,无法切换到运行状态");
    }
}

public class CloseState implements State {
    @Override
    public void open() {
        System.out.println("电梯开门");
        // 切换到开启状态
        context.setState(new OpenState());
    }

    @Override
    public void close() {
        System.out.println("电梯已经是关闭状态,无需再次关闭");
    }

    @Override
    public void run() {
        System.out.println("电梯开始运行");
        // 切换到运行状态
        context.setState(new RunState());
    }
}

public class RunState implements State {
    @Override
    public void open() {
        System.out.println("电梯在运行中,无法开门");
    }

    @Override
    public void close() {
        System.out.println("电梯关门");
        // 切换到关闭状态
        context.setState(new CloseState());
    }

    @Override
    public void run() {
        System.out.println("电梯已经是运行状态,无需再次运行");
    }
}

接下来,我们创建一个上下文类(Context),它包含了一个当前状态的引用,并提供对外的操作方法。

public class Context {
    private State currentState;

    public Context() {
        // 默认初始状态是关闭状态
        currentState = new CloseState();
    }

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

    public void open() {
        currentState.open();
    }

    public void close() {
        currentState.close();
    }

    public void run() {
        currentState.run();
    }
}

发现没有,上下文类里也有open()、close()、run()这三个方法,它并不自己实现,而是直接调用状态对象的同名方法。简单说,我们将上下文本该自己实现的方法放到了状态类里来实现,当然,这些方法的行为得受到状态的影响,不同状态下行为不同。

最后,我们可以使用上述的状态模式来模拟电梯的行为。

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

        context.open();  // 输出:"电梯开门"
        context.close();  // 输出:"电梯关闭门"
        context.run();  // 输出:"电梯开始运行"
        context.run();  // 输出:"电梯已经是运行状态,无需再次运行"
        context.open();  // 输出:"电梯在运行中,无法开门"
        context.close();  // 输出:"电梯关门"
        context.open();  // 输出:"电梯关闭门"
    }
}

通过上述示例,我们可以看到电梯根据不同的状态执行了相应的行为,而这些状态和行为的切换是相对灵活的。

这里,状态转换是在具体状态类中进行的,在严格的状态模式定义中,状态切换就是放在具体状态类中,这样的缺点是状态类之间有耦合,好处就是上下文里不用管状态的切换了。但也并不是只能如此。

Q.4 状态模式中,状态的切换应该放到具体状态类里还是上下文类里呢

A.4

在状态模式中,状态的切换可以放到具体状态类里,也可以放到上下文类里,具体取决于具体应用的需求和设计的考虑。

如果状态的变化是由外部条件驱动的,如用户的操作、外部事件等,那么通常将状态切换的逻辑放到上下文类中更为合适。上下文类可以根据外部条件来决定状态转换的时机,并调用具体状态类的方法来进行状态切换。

如果状态的变化是由内部条件驱动的,即状态类自身的逻辑或标记决定了状态的切换,那么将状态切换的逻辑放到具体状态类中更为合适。具体状态类知道自己的状态和状态转换的规则,可以自主地改变上下文对象的状态。

需要注意的是,无论状态的切换逻辑放在哪里,上下文对象和具体状态类之间都需要有适当的通信机制,以便完成状态切换后的行为执行。

综上所述,根据具体的应用需求和设计考虑,可以将状态的切换逻辑放到具体状态类或上下文类中。这也是状态模式的灵活性之一,可以根据不同的情况进行具体的设计选择。

希望这个解答对你有帮助。如果还有其他问题,请随时提问。

Q.5 上面的例子不错,就是给我换成c++语言吧

A.5

当然,没有问题!这是一个使用C++语言实现状态模式的电梯示例:

#include <iostream>

// 前向声明
class Context;

// 状态基类
class State {
public:
    virtual void open(Context* context) = 0;
    virtual void close(Context* context) = 0;
    virtual void run(Context* context) = 0;
};

// 具体状态类:开启状态
class OpenState : public State {
public:
    void open(Context* context) override {
        std::cout << "电梯已经是开启状态,无需再次开门" << std::endl;
    }

    void close(Context* context) override {
        std::cout << "电梯关闭门" << std::endl;
        // 切换到关闭状态
        context->setState(new CloseState());
    }

    void run(Context* context) override {
        std::cout << "电梯正在运行,无法切换到运行状态" << std::endl;
    }
};

// 具体状态类:关闭状态
class CloseState : public State {
public:
    void open(Context* context) override {
        std::cout << "电梯开门" << std::endl;
        // 切换到开启状态
        context->setState(new OpenState());
    }

    void close(Context* context) override {
        std::cout << "电梯已经是关闭状态,无需再次关闭" << std::endl;
    }

    void run(Context* context) override {
        std::cout << "电梯开始运行" << std::endl;
        // 切换到运行状态
        context->setState(new RunState());
    }
};

// 具体状态类:运行状态
class RunState : public State {
public:
    void open(Context* context) override {
        std::cout << "电梯在运行中,无法开门" << std::endl;
    }

    void close(Context* context) override {
        std::cout << "电梯关门" << std::endl;
        // 切换到关闭状态
        context->setState(new CloseState());
    }

    void run(Context* context) override {
        std::cout << "电梯已经是运行状态,无需再次运行" << std::endl;
    }
};

// 上下文类
class Context {
public:
    Context() {
        // 默认初始状态是关闭状态
        currentState = new CloseState();
    }

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

    void open() {
        currentState->open(this);
    }

    void close() {
        currentState->close(this);
    }

    void run() {
        currentState->run(this);
    }

private:
    State* currentState;
};

int main() {
    Context context;

    context.open();  // 输出:"电梯开门"
    context.close();  // 输出:"电梯关闭门"
    context.run();  // 输出:"电梯开始运行"
    context.run();  // 输出:"电梯已经是运行状态,无需再次运行"
    context.open();  // 输出:"电梯在运行中,无法开门"
    context.close();  // 输出:"电梯关门"
    context.open();  // 输出:"电梯关闭门"

    return 0;
}

在C++的实现中,我们使用了类和虚函数来表示状态和行为,实现了上下文类以及具体状态类。通过创建具体状态类的对象并切换状态,来模拟电梯的行为。

这里补充一下这个例子的类图。容易发现,上下文类 Context 拥有 state 类中定义的三个方法,它们分别调用了 state 类中的同名方法。状态的转换是在三个具体状态类中进行的,图中并未体现。

是否发现状态模式的类图和策略模式的类图是一样的呢?仔细看,确实是一样的。但要注意两者的应用场合是不一样的,在状态模式中,上下文类不需要了解各个状态对象,也不需要主动指定具体状态类,而在策略模式中,通常需要指定环境类使用的策略是哪一个。
可以说,脱落了应用场景,谈策略模式就意义不大了。

AI Chat 设计模式:11. 状态模式,设计模式,设计模式,c++,Chat AI,状态模式

Q.6 有一个问题,这些状态每次都是 new 出来的,但我却没看见它们在哪里销毁

A.6

这是一个很好的问题!在这个示例中,确实没有明确的地方将状态对象销毁。在实际应用中,可能需要在适当的时机销毁状态对象,以便释放内存和管理资源。

在状态模式中,通常有以下几种方式来处理状态对象的销毁:

  1. 手动销毁:在合适的时机手动删除状态对象。例如,在上下文类的析构函数中释放状态对象的内存。
  2. 使用智能指针:可以使用C++智能指针来管理状态对象的生命周期。例如,可以使用std::unique_ptr<State>来持有状态对象,并且在需要切换状态时,更新智能指针指向的对象。

这里是一种使用智能指针的示例代码:

// 上下文类
class Context {
public:
    Context() {
        // 默认初始状态是关闭状态
        currentState = std::make_unique<CloseState>();
    }

    void setState(std::unique_ptr<State> state) {
        currentState = std::move(state);
    }

    // ...

private:
    std::unique_ptr<State> currentState;
};

使用智能指针可以自动管理状态对象的生命周期,无需手动调用delete来释放内存。

记住,在使用智能指针时,需要确保在涉及到多个类之间的所有权传递时,正确地使用std::move()来转移所有权。

希望这个解答能解决你的疑问!如果还有其他问题,请随时提问。

Q.7 如果不使用智能指针呢

A.7

如果不使用智能指针,你可以手动管理状态对象的生命周期。这意味着你需要在适当的时候手动创建和销毁状态对象。

下面是一个示例代码,展示了如何手动管理状态对象的生命周期:

// 上下文类
class Context {
public:
    Context() {
        // 默认初始状态是关闭状态
        currentState = new CloseState();
    }

    void setState(State* state) {
        delete currentState; // 销毁当前状态对象
        currentState = state;
    }

    ~Context() {
        delete currentState; // 在销毁上下文对象时,销毁当前状态对象
    }

    // ...

private:
    State* currentState;
};

在这个示例中,我们使用了new来创建状态对象,并在需要切换状态时使用delete来销毁先前的状态对象。在上下文类的析构函数中,我们也进行了一次对象销毁

但需要注意的是,手动管理生命周期需要确保在正确的时机销毁对象,并避免出现内存泄漏或错误的删除对象的情况。在实际项目中,请谨慎使用并仔细考虑对象所有权的管理。

将状态对象的释放在了setState() 方法中,每次先删除旧状态。

Q.8 明白,现在每次切换状态都要删除老的状态类,创建新的状态类,如此的反复创建、销毁,有办法改进吗

A.8

是的,如果在状态切换过程中频繁创建和销毁状态对象,可能会导致性能问题。为了改进这个情况,可以考虑使用对象池(Object Pool)模式。

对象池模式是一种创建和维护对象池的设计模式,它可以重复使用已经创建的对象,而不是频繁地创建和销毁对象。通过对象池,可以减少对象创建和销毁的开销,提高性能。

下面是一个简化的示例代码,展示了如何使用对象池模式来管理状态对象:

// 对象池类
class ObjectPool {
public:
    ObjectPool() {
        // 初始化对象池,创建一定数量的状态对象
        for (int i = 0; i < POOL_SIZE; ++i) {
            pool.push(new State());
        }
    }

    State* acquireState() {
        if (pool.empty()) {
            // 如果对象池为空,可以选择扩展对象池大小或者返回一个默认的状态对象
            return new State();
        }
        else {
            State* state = pool.top();
            pool.pop();
            return state;
        }
    }

    void releaseState(State* state) {
        pool.push(state);
    }

private:
    std::stack<State*> pool;
    static const int POOL_SIZE = 10; // 对象池的大小,可以根据需求调整
};

// 上下文类
class Context {
public:
    Context() {
        // 默认初始状态是关闭状态
        currentState = objectPool.acquireState();
    }

    void setState(State* state) {
        objectPool.releaseState(currentState); // 释放先前的状态对象
        currentState = state;
    }

    ~Context() {
        objectPool.releaseState(currentState); // 在销毁上下文对象时,释放当前状态对象
    }

    // ...

private:
    State* currentState;
    static ObjectPool objectPool; // 共享的对象池
};

ObjectPool Context::objectPool; // 静态成员变量需要在类外进行定义

在这个示例中,我们创建了一个对象池(ObjectPool),它在初始化时创建了一定数量的状态对象,并提供了acquireStatereleaseState方法来获取和释放状态对象。

在上下文类(Context)中,通过调用acquireState方法来获取状态对象,并在需要切换状态时使用releaseState方法来释放先前的状态对象。这样可以重复使用对象,减少了创建和销毁的开销。

使用对象池模式可以改善频繁创建和销毁状态对象的性能问题。然而,需要根据具体的应用场景和需求来决定对象池的大小,以及在对象池不足时的处理方式。

现在切换状态时,不是直接 new 一个状态对象了,而是从对象池获取。
销毁旧状态对象时,其实并没有真正销毁,只是放回来对象池。

这个例子是有一定问题的,比如 acquireState() 方法应该加个参数,从而能获取不同的状态对象,例子里显然不能做到这一点。

记住优化思路就行了,就是将所有状态对象的创建和销毁交给另一个类来管理,切换状态时不再直接创建和销毁状态对象。

Q.9 不错,最后需要你对状态模式做一个全面的总结

A.9

状态模式是一种行为型设计模式,它允许对象在其内部状态发生改变时改变其行为。该模式将对象的状态封装成独立的状态类,使得状态的变化可以彼此替换而不影响使用状态的对象。通过使用状态模式,可以实现状态转换和行为的解耦,使得代码更加可维护、可扩展和可复用。

主要角色:

  1. 上下文(Context):上下文是包含了状态对象的环境类。它定义了一个接口,用于客户端和具体状态类之间的交互。
  2. 抽象状态(State):抽象状态是一个接口或抽象类,定义了具体状态类需要实现的方法,并且为上下文对象提供一个统一的接口。
  3. 具体状态(Concrete State):具体状态是抽象状态的具体实现,它根据上下文的状态变化来改变自己的行为。

工作原理:

  1. 定义状态:首先,需要识别对象的状态以及每个状态的行为。将每种状态都抽象成一个独立的状态类。
  2. 建立上下文:创建一个上下文类,它包含一个指向当前状态的引用,并提供可以触发状态转换和执行对应行为的方法。
  3. 实现状态:为每个状态实现相应的行为方法,并在需要时,从一个状态切换到另一个状态。

优点:

  1. 将状态转换的逻辑从上下文对象中分离出来,使得代码更加可读、可维护和可扩展。
  2. 将状态行为封装在独立的状态类中,可实现状态的复用,并且可以方便地添加新的状态。
  3. 减少了使用条件语句进行状态判断的情况,使得代码更加简洁和易于理解。

适用场景:

  1. 当一个对象的行为取决于其内部状态,并且需要在运行时根据状态改变行为时,可以考虑使用状态模式。
  2. 当对象具有大量重复的条件语句,以便根据不同的状态执行不同的行为时,可以使用状态模式简化代码结构。

总结起来,状态模式通过将状态封装成独立的状态类,使得状态的变化可以彼此替换而不影响使用状态的对象。它提供了一种可扩展、可维护和可复用的解决方案,能够简化代码结构,并将状态行为与上下文对象的交互进行解耦。

希望这个总结对你有帮助。如果还有任何问题,请随时提问。文章来源地址https://www.toymoban.com/news/detail-623813.html

到了这里,关于AI Chat 设计模式:11. 状态模式的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • AI Chat 设计模式:3. 原型模式

    本文是该系列的第三篇,采用问答式的方式展开,问题由我提出,答案由 Chat AI 作出,灰色背景的文字则主要是我的旁白。 好的,原型模式是一种创建型设计模式,它通过 克隆现有的对象来创建新对象 。这种模式的关键在于提供一个原型对象,客户端通过克隆原型对象创建

    2024年02月09日
    浏览(37)
  • AI Chat 设计模式:8. 门面(外观)模式

    本文是该系列的第八篇,采用问答式的方式展开,问题由我提出,答案由 Chat AI 作出,灰色背景的文字则主要是我的一些思考和补充。 门面模式(Facade Pattern)是一种结构型设计模式,它 提供了一个简单的接口,用于统一封装子系统中的一组接口 ,并将其展示给客户端。门

    2024年02月16日
    浏览(36)
  • AI Chat 设计模式:12. 享元模式

    本文是该系列的第十二篇,采用问答式的方式展开,问题由我提出,答案由 Chat AI 作出,灰色背景的文字则主要是我的一些思考和补充。 享元模式是一种软件设计模式,用于 提高系统的性能和内存利用率 。该模式 通过共享对象来减少内存消耗 ,特别是在大量对象需要同时

    2024年02月14日
    浏览(39)
  • AI Chat 设计模式:7. 单例模式

    本文是该系列的第七篇,采用问答式的方式展开,问题由我提出,答案由 Chat AI 作出,灰色背景的文字则主要是我的旁白和思考。 单例模式是一种设计模式,旨在 确保类只能有一个实例 ,并提供全局访问点来获取该实例。这意味着无论在系统中的哪个位置,调用者获取到的

    2024年02月16日
    浏览(39)
  • AI Chat 设计模式:14. 适配器模式

    本文是该系列的第十四篇,采用问答式的方式展开,问题由我提出,答案由 Chat AI 作出,灰色背景的文字则主要是我的一些思考和补充。 适配器模式是一种常用的设计模式,用于将一个类的接口转换成客户端所期望的另一个接口。如果要由浅入深地了解适配器模式,我可以提

    2024年02月12日
    浏览(38)
  • 4.设计模式之后七种模式后11种模式命令访问者迭代器发布订阅中介者忘备录解释器状态策略职责链和空模式

    1.命令(command)模式 不知道命令接收者(对象)是谁,支持撤销 (接受者 间接调用执行 的具体行为) 命令调用者和接收者解耦 //只要实现命令接口即可 (就是客户端给个命令,然后命令类传给接收类执行) 优点和缺点 容易撤销操作 命令队列可以多线程操作 增加过多的命令类 空命令也

    2024年02月12日
    浏览(63)
  • 《设计模式》状态模式

    定义 : 状态模式也称为状态机模式, 允许对象在内部状态发生改变时改变它的行为,对象看起来好像修改了它的类。 属于 行为型 模式。 状态模式的角色组成 : State(抽象状态类) :定义一个接口用来封装与环境类的一个特定状态相关的行为,可以有一个或多个行为。 Con

    2024年02月05日
    浏览(36)
  • 设计模式:状态模式示例

    状态模式可以应用于多种场景,下面是一些示例及其代码实现: 1. 交通信号灯 交通信号灯(红灯、绿灯、黄灯)根据当前状态切换到下一个状态。 2. 游戏角色等级系统 游戏中的角色根据经验值提升等级,不同等级有不同的行为。 这两个示例展示了状态模式在不同场景下的

    2024年04月23日
    浏览(29)
  • 设计模式-状态模式

    一个对象有状态变化 每次状态变化都会触发一个逻辑 不能总是用 if else 来控制 交通信号灯不同颜色的变化 传统UML类图 简化后的UML类图 有限个状态、以及在这些状态之间的变化 如交通信号灯 使用开源lib:javascript-state-machine github.com/jakesgordon/javascript-state-machine 有限状态机

    2024年02月07日
    浏览(42)
  • 设计模式_状态模式

    介绍 设计模式 定义 案例 问题堆积在哪里 解决办法 状态模式 一个对象 状态可以发生改变 不同的状态又有不同的行为逻辑 游戏角色 加载不同的技能 每个技能有不同的:攻击逻辑 攻击范围 动作等等 1 状态很多 2 每个状态有自己的属性和逻辑 每种状态单独写一个类 角色需要

    2024年02月06日
    浏览(36)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包