设计模式学习笔记 - 设计模式与范式 -行为型:8.状态模式:游戏、工作流引擎中常用的状态机是如何实现的?

这篇具有很好参考价值的文章主要介绍了设计模式学习笔记 - 设计模式与范式 -行为型:8.状态模式:游戏、工作流引擎中常用的状态机是如何实现的?。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

概述

本章学习状态模式。在实际的开发中,状态模式并不是很常用,但是在能够用到的场景里,它可以发挥很大的作用。从这一点上看,它有点像我们之前讲到的组合模式。

状态模式一般用来实现状态机,而状态机常用在游戏、工作流引擎等系统开发中。不过,状态机的实现方式有很多种,除了状态模式,比较常用的还有分支逻辑法和查表法。本章就详细讲讲这几种实现方式,并且对比一下它们的优劣和应用场景。


什么是有限状态机

有限状态机,英文翻译是 Finite State Machine,缩写为 FSM,简称状态机。状态机有三个组成部分:状态(State)、事件(Event)、动作(Action)。

  • 事件也称为转移条件(Transaction Condition)。
  • 事件触发状态的转移及动作的执行。
  • 不过,动作不是必须得,也可能只转移状态,不执行任何动作。

对于刚刚给出的状态机定义,结合一个具体的例子进行解释。

“超级马里奥” 游戏不知道你玩过没有?在游戏中,马里奥可以变身为多种形态,比如小马里奥(Small Mario)、超级马里奥(Super Mario)、火焰马里奥(Fire Mario)、斗篷马里奥(Cape Mario)等等。在不同的游戏情节下,各个形态会互相转化,并相应地增减积分。比如,初始状态是小马里奥,吃了蘑菇后就变成超级马里奥,并且增加 100 积分。

实际上,马里奥形态的转变就是一个状态机。其中,马里奥的不同形态就是状态机种的 “状态”,游戏情节(比如吃了蘑菇)就是状态机种的 “事件”,加减积分就是状态机种的 “动作”。比如,吃蘑菇这个事件,会触发状态的转移(从小马里奥转移到超级马里奥),以及触发动作的执行(增加 100 积分)。

为方便讲解,我对游戏背景做了简化,只保留了部分状态和事件,简化之后的状态转移如下所示:

设计模式学习笔记 - 设计模式与范式 -行为型:8.状态模式:游戏、工作流引擎中常用的状态机是如何实现的?,设计模式-实战,状态模式
如何编程来实现上面的状态机呢?

我写了个骨架代码,如下所示。其中,obtainMushRoom()obtainCape()obtainFileFlower()meetMonster() 这个几个函数,能够根据当前的状态和事件,更新状态和增减积分。不过,具体的代码实现暂时没给出。你可以先试着自己补全一下。

public enum State {
    SMALL(0),
    SUPER(1),
    FIRE(2),
    CAPE(3),
    ;

    private int value;

    State(int value) {
        this.value = value;
    }

    public int getValue() {
        return value;
    }
}

public class MarioStateMachine {
    private int score;
    private State currentState;

    public MarioStateMachine() {
        this.score = 0;
        this.currentState = State.SMALL;
    }

    public void obtainMushRoom() {
        //TODO
    }

    public void obtainCape() {
        //TODO
    }

    public void obtainFireFlower() {
        //TODO
    }

    public void meetMonster() {
        //TODO
    }

    public int getScore() {
        return score;
    }

    public State getState() {
        return currentState;
    }
}

public class ApplicationDemo {
    public static void main(String[] args) {
        MarioStateMachine mario = new MarioStateMachine();
        mario.obtainMushRoom();
        int score = mario.getScore();
        State state = mario.getState();
        System.out.println("mario score: " + score + "; state: " + state);
    }
}

状态机实现方式一:分支逻辑法

对于如何实现状态机,有三种方式。其中,最简单直接的实现方式是,参照状态转移图,将每一个状态转移,原模原样地直译成代码。这样编写的代码会包含大量的 if-esle 或 switch-else 分支判断逻辑,甚至是嵌套的分支判断逻辑,所以,我把这种方法暂且命名为分支逻辑法

按照这个思路,将上面的骨架代码补全一下。补全之后的代码如下所示:

public class MarioStateMachine {
    private int score;
    private State currentState;

    public MarioStateMachine() {
        this.score = 0;
        this.currentState = State.SMALL;
    }

    public void obtainMushRoom() {
        if (currentState == State.SMALL) {
            this.currentState = State.SUPER;
            this.score += 100;
        }
    }

    public void obtainCape() {
        if (currentState == State.SMALL || currentState == State.SUPER) {
            this.currentState = State.CAPE;
            this.score += 200;
        }
    }

    public void obtainFireFlower() {
        if (currentState == State.SMALL || currentState == State.SUPER) {
            this.currentState = State.FIRE;
            this.score += 300;
        }
    }

    public void meetMonster() {
        if (currentState == State.SUPER) {
            this.currentState = State.SMALL;
            this.score -= 100;
        }
        if (currentState == State.CAPE) {
            this.currentState = State.SMALL;
            this.score -= 200;
        }
        if (currentState == State.FIRE) {
            this.currentState = State.SMALL;
            this.score -= 300;
        }
    }

    public int getScore() {
        return score;
    }

    public State getState() {
        return currentState;
    }
}

对于简单的状态机来说,分支逻辑这种实现方式是可以接收的。但是,对于复杂的状态机来说,这种实现方式及其容易漏写或错写某个状态转移。此外,代码中充斥着大量的 if-else 或者 switch-case 分支判断逻辑,可读性和可维护性都很差。如果哪些修改了状态机种的某个转移,我们要在冗长的分支逻辑中找到对应地代码进行修改,很容易改错,引入 BUG。

状态机实现方式二:查表法

实际上,上面的实现方式有点类似 hard code,对于复杂的状态机来说不适用,而状态机的第二种实现方式查表法,就更加合适了。接下来,看下如何利用查表法来补全骨架代码。

实际上,除了用状态转移图来表示之外,状态机还可以用二维表来表示,如下所示。这个二维表中,第一维表示当前的状态,第二维表示当前状态经过事件之后,转移到的新状态及其执行的动作。

E1(Got MushRoom) E2(Got Cape) E3(Got Fire Flower) E4(Meet Monster)
Small Super/+100 Cape/+200 Fire/+300 /
Super / Cape/+200 Fire/+300 Small/-100
Cape / / / Small/-200
Fire / / / Small/-300

注:表中的斜杠表示不存在这种状态转移

相对于分支逻辑的实现方式,查表法的代码实现更加清晰,可读性和可维护性更好。当修改状态机时,我们只需要修改 transactionTableactionTable 两个二维数组即可。实际上,如果我们把二维数组存储在配置文件中,当需要修改状态机时,甚至可以不修改代码,只需要修改配置文件就可以了。具体代码如下所示:

public enum Event {
    GOT_MUSHROOM(0),
    GOT_CAPE(1),
    GOT_FIRE(2),
    MEET_MONSTER(3),
    ;

    private int value;

    Event(int value) {
        this.value = value;
    }

    public int getValue() {
        return value;
    }
}

public class MarioStateMachine {
    private int score;
    private State currentState;

    private static final State[][] transitionTable = {
            {SUPER, CAPE, FIRE, SMALL},
            {SUPER, CAPE, FIRE, SMALL},
            {CAPE, CAPE, CAPE, SMALL},
            {FIRE, FIRE, FIRE, SMALL}
    };

    private static final int[][] actionTable = {
            {100, 200, 300, 0},
            {0, 200, 300, -100},
            {0, 0, 0, -200},
            {0, 0, 0, -300},
    };

    public MarioStateMachine() {
        this.score = 0;
        this.currentState = State.SMALL;
    }

    public void obtainMushRoom() {
        executeEvent(Event.GOT_MUSHROOM);
    }

    public void obtainCape() {
        executeEvent(Event.GOT_CAPE);
    }

    public void obtainFireFlower() {
        executeEvent(Event.GOT_FIRE);
    }

    public void meetMonster() {
        executeEvent(Event.MEET_MONSTER);
    }

    private void executeEvent(Event event) {
        int stateValue = currentState.getValue();
        int eventValue = event.getValue();
        this.currentState = transitionTable[stateValue][eventValue];
        this.score += actionTable[stateValue][eventValue];
    }

    public int getScore() {
        return score;
    }

    public State getState() {
        return currentState;
    }
}

状态机实现方式三:状态模式

在查表法的代码实现中,事件触发的动作只能是简单的积分加减,所以,我们用一个 int 类型的二维数组 actionTable 就能表示,二维数组中的值表示积分的加减值。但是,如果要执行的动作并非这么简单,而是一系列复杂的逻辑操作(比如加减积分、写数据库,还有可能发送消息通知等等),我们就没法用如此简单的二维数组来表示了。也就是说,查表法的实现方式有一定的局限性。

虽然分支逻辑的实现方式不存在这个问题,但它又存在前面讲到的其他问题,比如分支判断逻辑较多,导致代码的可读性和可维护性不好等。实际上,对于分支逻辑法存在的问题,可以使用状态模式来解决。

状态模式通过将事件触发的状态转移和动作执行,拆分到不同的类中,来避免分支判断逻辑。我们还是结合代码来理解这句话。

其中,IMario 是状态的接口,定义了所有事件。SmallMarioSuperMarioCapeMarioFireMarioIMario 接口的实现类,分别对应状态机种的 4 个状态。原来所有的状态转移和动作执行的代码逻辑,都集中在 MarioStateMachine 中,现在,这些代码被拆分到了这 4 个状态类中。

public interface IMario {
    State getName();
    // 以下是定义的事件
    void obtainMushRoom();
    void obtainCape();
    void obtainFireFlower();
    void meetMonster();
}

public class SmallMario implements IMario {
    private MarioStateMachine stateMachine;

    public SmallMario(MarioStateMachine stateMachine) {
        this.stateMachine = stateMachine;
    }

    @Override
    public State getName() {
        return State.SMALL;
    }

    @Override
    public void obtainMushRoom() {
        stateMachine.setCurrentState(new SuperMario(stateMachine));
        stateMachine.setScore(stateMachine.getScore() + 100);
    }

    @Override
    public void obtainCape() {
        stateMachine.setCurrentState(new CapeMario(stateMachine));
        stateMachine.setScore(stateMachine.getScore() + 200);
    }

    @Override
    public void obtainFireFlower() {
        stateMachine.setCurrentState(new FireMario(stateMachine));
        stateMachine.setScore(stateMachine.getScore() + 300);
    }

    @Override
    public void meetMonster() {
        // do nothing...
    }
}

public class SuperMario implements IMario {
    private MarioStateMachine stateMachine;

    public SuperMario(MarioStateMachine stateMachine) {
        this.stateMachine = stateMachine;
    }

    @Override
    public State getName() {
        return State.SUPER;
    }


    @Override
    public void obtainMushRoom() {
        // do nothing...
    }

    @Override
    public void obtainCape() {
        stateMachine.setCurrentState(new CapeMario(stateMachine));
        stateMachine.setScore(stateMachine.getScore() + 200);
    }

    @Override
    public void obtainFireFlower() {
        stateMachine.setCurrentState(new FireMario(stateMachine));
        stateMachine.setScore(stateMachine.getScore() + 300);
    }

    @Override
    public void meetMonster() {
        stateMachine.setCurrentState(new SmallMario(stateMachine));
        stateMachine.setScore(stateMachine.getScore() - 100);
    }
}

public class CapeMario implements IMario {
    private MarioStateMachine stateMachine;

    public CapeMario(MarioStateMachine stateMachine) {
        this.stateMachine = stateMachine;
    }

    @Override
    public State getName() {
        return State.CAPE;
    }

    @Override
    public void obtainMushRoom() {
        // do nothing...
    }

    @Override
    public void obtainCape() {
        // do nothing...
    }

    @Override
    public void obtainFireFlower() {
        stateMachine.setCurrentState(new FireMario(stateMachine));
        stateMachine.setScore(stateMachine.getScore() + 300);
    }

    @Override
    public void meetMonster() {
        stateMachine.setCurrentState(new SmallMario(stateMachine));
        stateMachine.setScore(stateMachine.getScore() - 200);
    }
}

public class FireMario implements IMario {
    private MarioStateMachine stateMachine;

    public FireMario(MarioStateMachine stateMachine) {
        this.stateMachine = stateMachine;
    }

    @Override
    public State getName() {
        return State.FIRE;
    }


    @Override
    public void obtainMushRoom() {
        // do nothing...
    }

    @Override
    public void obtainCape() {
        // do nothing...
    }

    @Override
    public void obtainFireFlower() {
        // do nothing...
    }

    @Override
    public void meetMonster() {
        stateMachine.setCurrentState(new SmallMario(stateMachine));
        stateMachine.setScore(stateMachine.getScore() - 300);
    }
}

public class MarioStateMachine {
    private int score;
    private IMario currentState; // 不在使用枚举表示状态

    public MarioStateMachine() {
        this.score = 0;
        this.currentState = new SmallMario(this);
    }

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

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

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

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

    public int getScore() {
        return score;
    }

    public void setScore(int score) {
        this.score = score;
    }

    public void setCurrentState(IMario currentState) {
        this.currentState = currentState;
    }

    public IMario getState() {
        return currentState;
    }
}

上面的代码实现不难看懂,只需要注意一点,即 MarioStateMachine 和各个状态类之间是双向依赖关系。 MarioStateMachine 依赖各个类是理所当然的,但是反过来,各个状态类为什么要依赖 MarioStateMachine 呢? 这是因为,各个状态类需要更新 MarioStateMachine 中的属性, scorecurrentState

实际上,上面的代码还可以继续优化,可以将状态类设置成单例,比较状态类中不包含任何成员变量。但是,当状态类设计成单例之后,就无法通过构造函数来传递 MarioStateMachine 了,而状态类又要依赖 MarioStateMachine ,那该如何解决呢?

实际上,在《创建型:2.单例模式(中):为什么不推荐使用单例模式?又有何替代方案?》中,提到过集中解决方法,你可以回过头去查看下。在这里,可以通过函数参数将 MarioStateMachine 传递进状态类。根据这个设计思路,对上面的代码进行重构。重构之后的代码如下所示:

public interface IMario {
    State getName();
    // 以下是定义的事件
    void obtainMushRoom(MarioStateMachine stateMachine);
    void obtainCape(MarioStateMachine stateMachine);
    void obtainFireFlower(MarioStateMachine stateMachine);
    void meetMonster(MarioStateMachine stateMachine);
}

public class SmallMario implements IMario {
    private static final SmallMario instance = new SmallMario();
    private SmallMario() {
    }
    public static SmallMario getInstance() {
        return instance;
    }

    @Override
    public State getName() {
        return State.SMALL;
    }

    @Override
    public void obtainMushRoom(MarioStateMachine stateMachine) {
        stateMachine.setCurrentState(SuperMario.getInstance());
        stateMachine.setScore(stateMachine.getScore() + 100);
    }

    @Override
    public void obtainCape(MarioStateMachine stateMachine) {
        stateMachine.setCurrentState(CapeMario.getInstance());
        stateMachine.setScore(stateMachine.getScore() + 200);
    }

    @Override
    public void obtainFireFlower(MarioStateMachine stateMachine) {
        stateMachine.setCurrentState(FireMario.getInstance());
        stateMachine.setScore(stateMachine.getScore() + 300);
    }

    @Override
    public void meetMonster(MarioStateMachine stateMachine) {
        // do nothing...
    }
}

public class SuperMario implements IMario {
    private static final SuperMario instance = new SuperMario();
    private SuperMario() {
    }
    public static SuperMario getInstance() {
        return instance;
    }

    @Override
    public State getName() {
        return State.SUPER;
    }


    @Override
    public void obtainMushRoom(MarioStateMachine stateMachine) {
        // do nothing...
    }

    @Override
    public void obtainCape(MarioStateMachine stateMachine) {
        stateMachine.setCurrentState(CapeMario.getInstance());
        stateMachine.setScore(stateMachine.getScore() + 200);
    }

    @Override
    public void obtainFireFlower(MarioStateMachine stateMachine) {
        stateMachine.setCurrentState(FireMario.getInstance());
        stateMachine.setScore(stateMachine.getScore() + 300);
    }

    @Override
    public void meetMonster(MarioStateMachine stateMachine) {
        stateMachine.setCurrentState(SmallMario.getInstance());
        stateMachine.setScore(stateMachine.getScore() - 100);
    }
}

public class CapeMario implements IMario {
    private static final CapeMario instance = new CapeMario();
    private CapeMario() {
    }
    public static CapeMario getInstance() {
        return instance;
    }

    @Override
    public State getName() {
        return State.CAPE;
    }

    @Override
    public void obtainMushRoom(MarioStateMachine stateMachine) {
        // do nothing...
    }

    @Override
    public void obtainCape(MarioStateMachine stateMachine) {
        // do nothing...
    }

    @Override
    public void obtainFireFlower(MarioStateMachine stateMachine) {
        stateMachine.setCurrentState(FireMario.getInstance());
        stateMachine.setScore(stateMachine.getScore() + 300);
    }

    @Override
    public void meetMonster(MarioStateMachine stateMachine) {
        stateMachine.setCurrentState(SmallMario.getInstance());
        stateMachine.setScore(stateMachine.getScore() - 200);
    }
}

public class FireMario implements IMario {
    private static final FireMario instance = new FireMario();
    private FireMario() {
    }
    public static FireMario getInstance() {
        return instance;
    }

    @Override
    public State getName() {
        return State.FIRE;
    }


    @Override
    public void obtainMushRoom(MarioStateMachine stateMachine) {
        // do nothing...
    }

    @Override
    public void obtainCape(MarioStateMachine stateMachine) {
        // do nothing...
    }

    @Override
    public void obtainFireFlower(MarioStateMachine stateMachine) {
        // do nothing...
    }

    @Override
    public void meetMonster(MarioStateMachine stateMachine) {
        stateMachine.setCurrentState(SmallMario.getInstance());
        stateMachine.setScore(stateMachine.getScore() - 300);
    }
}

public class MarioStateMachine {
    private int score;
    private IMario currentState; // 不在使用枚举表示状态

    public MarioStateMachine() {
        this.score = 0;
        this.currentState = SmallMario.getInstance();
    }

    public void obtainMushRoom() {
        currentState.obtainMushRoom(this);
    }

    public void obtainCape() {
        currentState.obtainCape(this);
    }

    public void obtainFireFlower() {
        currentState.obtainFireFlower(this);
    }

    public void meetMonster() {
        currentState.meetMonster(this);
    }

    public int getScore() {
        return score;
    }

    public void setScore(int score) {
        this.score = score;
    }

    public void setCurrentState(IMario currentState) {
        this.currentState = currentState;
    }

    public IMario getState() {
        return currentState;
    }
}

实际上,像游戏这种比较复杂的状态机,包含的状态比较多,优先推荐使用查表法,而状态模式会引入非常多的状态类,会导致代码比较难维护。

相反,像电商下单、外卖下单这种类型的状态机,它们的状态并不多,状态转移也比较简单,但事件触发执行的动作包含的业务逻辑可能会比较复杂,所以更加推荐使用状态模式来实现。

总结

本章讲解了状态模式。虽然网上有各种各样的状态模式,但是你只要记住状态模式是状态机的一种实现方式即可

状态机又叫有限状态机,它由3部分组成:状态、事件、动作。

  • 其中事件也称为转移条件。
  • 事件触发状态的转移及动作的执行。
  • 不过动作不是必须的,也可能只转移状态,不执行任何动作。

针对状态机,本章总结了三种实现方式。文章来源地址https://www.toymoban.com/news/detail-846343.html

  • 第一种实现方式叫分支逻辑法。利用 if-else 或 switch-case 分支逻辑,参照状态转移图,将每个状态转移原模原样的直译成代码。对于简单的状态机来说,这种实现方式最简单、最直接,是首选。
  • 第二种实现方式叫查表法。对于状态很多、状态转移比较复杂的状态机来说,查表法比较合适。通过二维素组来表示状态转移图,能极大地提高代码的可读性和可维护性。
  • 第三张实现方式叫状态模式。对于状态不多、状态转移也比较简单,但事件触发执行的动作包含的业务逻辑可能比较复杂的状态机来说,首选这种实现方式。

到了这里,关于设计模式学习笔记 - 设计模式与范式 -行为型:8.状态模式:游戏、工作流引擎中常用的状态机是如何实现的?的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

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

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

相关文章

  • 【设计模式与范式:行为型】61 | 策略模式(下):如何实现一个支持给不同大小文件排序的小程序?

    上一节课,我们主要介绍了策略模式的原理和实现,以及如何利用策略模式来移除 if-else 或者 switch-case 分支判断逻辑。今天,我们结合“给文件排序”这样一个具体的例子,来详细讲一讲策略模式的设计意图和应用场景。 除此之外,在今天的讲解中,我还会通过一步一步地

    2024年02月10日
    浏览(41)
  • 行为型设计模式——状态模式

    状态模式是比较简单的设计模式,它的主要作用是减少代码中大量的 if-else 或者 switch-case 等逻辑判断(俗称屎山)。它将每个状态定义为一个类,而每个状态类有自己对应的方法,因此当需要根据状态执行逻辑代码时不需要写大量的if-else判断是哪个状态然后执行对应的逻辑

    2024年02月02日
    浏览(49)
  • 设计模式行为型——状态模式

      目录 状态模式的定义 状态模式的实现 状态模式角色 状态模式类图 状态模式举例 状态模式代码实现 状态模式的特点 优点 缺点 使用场景 注意事项 实际应用        在软件开发过程中,应用程序中的部分对象可能会根据不同的情况做出不同的行为,把这种对象称为有状态

    2024年02月14日
    浏览(39)
  • 设计模式行为型-状态模式

    状态模式是一种行为型设计模式,用于处理对象在不同状态下的行为变化。它将对象的行为封装在不同状态类中,通过状态的切换实现不同行为的触发。 本文将介绍状态模式的基本概念、应用场景以及优势与适用性。 实现具体状态类 具体工作类: 上下文类包含状态对象的引

    2024年02月10日
    浏览(39)
  • 【设计模式与范式:行为型】69 | 访问者模式(下):为什么支持双分派的语言不需要访问者模式?

    上一节课中,我们学习了访问者模式的原理和实现,并且还原了访问者模式诞生的思维过程。总体上来讲,这个模式的代码实现比较难,所以应用场景并不多。从应用开发的角度来说,它的确不是我们学习的重点。 不过,我们前面反复说过,学习我的专栏,并不只是让你掌握

    2024年02月10日
    浏览(48)
  • 设计模式—行为型模式之状态模式

    状态(State)模式:对有状态的对象,把复杂的“判断逻辑”提取到不同的状态对象中,允许状态对象在其内部状态发生改变时改变其行为。 状态模式包含以下主要角色: 环境类(Context)角色:也称为上下文,它定义了客户端需要的接口,内部维护一个当前状态,并负责具

    2024年01月15日
    浏览(35)
  • 设计模式学习笔记 - 开源实战三(下):借助Google Guava学习三大编程范式中的函数式编程

    现在主流的编程范式主要有三种,面向过程、面向对象和函数式编程。在理论部分,已经介绍了前面两种编程范式。本章再讲讲剩下的编程范式,函数式编程。 函数式编程并非是一个很新的东西,早在 50 年前就已经出现。近几年,函数式编程越来越被人关注,出现了很多新

    2024年04月22日
    浏览(54)
  • 【十五】设计模式~~~行为型模式~~~状态模式(Java)

    【学习难度:★★★☆☆,使用频率:★★★☆☆】 在很多情况下,一个对象的行为取决于一个或多个动态变化的属性,这样的属性叫做状态,这样的对象叫做有状态的(stateful)对象,这样的对象状态是从事先定义好的一系列值中取出的。当一个这样的对象与外部事件产生互

    2024年02月07日
    浏览(49)
  • 笨蛋学设计模式行为型模式-状态模式【20】

    8.7.1概念 ​ 状态模式是指对象在运行时可以根据内部状态的不同而改变它们的行为,该模式将内部状态的行为封装为不同的具体状态类中,并将状态转换逻辑委托给这些状态类来处理,当对象的内部状态发生变化时,它会自动切换到对应的状态类,从而改变其行为。 8.7.2场景

    2024年01月23日
    浏览(37)
  • 【地铁上的设计模式】--行为型模式:状态模式

    什么是状态模式 状态模式是一种行为模式,它允许对象在其内部状态发生改变时改变其行为。在状态模式中,将状态定义为独立的对象,并将对象在不同状态下的行为委托给具有相应行为的状态对象。当对象的状态发生变化时,它将使用不同的状态对象来执行不同的操作,从

    2024年02月04日
    浏览(47)

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

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

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

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

二维码1

领取红包

二维码2

领红包