状态设计模式的替代方案及音频播放器的其他设计模式实现

一、状态模式的最佳直接替代方案：集中式有限状态机（FSM） #

状态模式把状态行为和转移逻辑分散到各个状态类中，确实容易导致状态间耦合、整体可读性下降——尤其是当状态转移规则散落在多个类里时，你很难一眼理清所有状态的流转路径。

集中式FSM是最直接的替代方案，它把所有状态定义、行为逻辑、转移规则都集中在同一处（比如播放器类内部），常见实现方式有两种：

• 枚举+Switch/Case：用枚举定义所有状态（如PLAYING、PAUSED、STOPPED），播放器维护当前状态，在处理play()、pause()等方法时，通过switch判断当前状态，执行对应行为并完成状态转移。
• 状态映射表：用字典（或哈希表）存储“当前状态+触发事件”到“目标状态+执行行为”的映射，播放器触发事件时直接查表执行，比switch更灵活，适合状态较多的场景。

这种方式的核心优势是所有状态逻辑集中可见，完美解决了状态模式中分散耦合的问题，对于音频播放器这类状态数量不多、转移逻辑清晰的场景，可读性和维护性反而更高。

二、用其他设计模式搭建音频播放器类 #

结合音频播放器的核心需求（状态管理、操作触发），可以用以下几种模式实现：

1. 集中式FSM（最推荐） #

以伪代码为例：

enum PlayerState { STOPPED, PLAYING, PAUSED }

class AudioPlayer {
    private PlayerState currentState = PlayerState.STOPPED;
    private AudioFile currentTrack;

    public void play() {
        switch(currentState) {
            case STOPPED:
                currentTrack.start();
                currentState = PlayerState.PLAYING;
                break;
            case PAUSED:
                currentTrack.resume();
                currentState = PlayerState.PLAYING;
                break;
            case PLAYING:
                // 已在播放，无需操作
                break;
        }
    }

    public void pause() {
        switch(currentState) {
            case PLAYING:
                currentTrack.pause();
                currentState = PlayerState.PAUSED;
                break;
            case STOPPED:
            case PAUSED:
                // 无需操作
                break;
        }
    }

    // stop()等方法逻辑类似
}

所有状态逻辑都封装在播放器类内部，状态转移路径一目了然，完全避免了状态类之间的依赖问题。

2. 策略模式变种 #

把每个状态下的行为封装成独立的策略类，但状态转移逻辑由播放器类控制，而非让策略类互相调用：

• 定义PlayerStrategy接口，包含onPlay()、onPause()、onStop()方法；
• 分别实现StoppedStrategy、PlayingStrategy、PausedStrategy，每个策略只处理当前状态下的行为（比如StoppedStrategy的onPlay()负责启动音频）；
• 播放器类维护当前策略，触发操作时调用当前策略的对应方法，再由播放器自身判断并切换到目标策略。

这种方式既保留了策略模式的职责分离特性，又避免了状态模式中状态类互相依赖的问题，适合需要对单个状态行为做复杂扩展的场景。

3. 命令模式（适合操作扩展场景） #

如果播放器需要支持操作撤销、批量操作队列等功能，可以用命令模式：

• 定义PlayerCommand接口，包含execute()方法；
• 实现PlayCommand、PauseCommand、StopCommand等命令类，每个命令持有播放器引用，执行时先判断当前状态再调用底层音频控制方法；
• 播放器类作为接收者，提供startTrack()、pauseTrack()等底层方法，同时可维护命令历史队列用于撤销操作。

这种方式把操作逻辑和状态判断解耦，适合功能复杂的播放器场景。

总结 #

如果只是想解决状态模式的耦合和可读性问题，集中式FSM是最佳替代；如果需要兼顾职责分离，选择策略模式变种；如果需要操作扩展（如撤销、队列），则用命令模式。音频播放器这类状态简单的场景，集中式FSM是最省心的实现方式。

内容的提问来源于stack exchange，提问作者Himanshu Naidu