Golang命令模式如何解耦调用者与执行者_命令封装设计

Go中命令模式核心是定义无参无返回值的Command接口，通过结构体封装Receiver和参数实现解耦，Invoker仅依赖接口执行命令，Undo需命令自行保存上下文。

Golang命令模式如何解耦调用者与执行者_命令封装设计第1张

Go 语言没有内置的命令模式（Command Pattern）支持，但用接口 + 结构体能干净解耦调用者（Invoker）和执行者（Receiver），关键在于把「做什么」和「谁来做」彻底分离。

如何定义 `Command` 接口与基础实现

核心是抽象出统一的执行契约。Go 里最自然的方式是定义一个无参、无返回值的函数接口：

type Command interface {
    Execute()
}

所有具体命令都实现它。注意：不要带参数或 error 返回——参数应封装进结构体字段，错误应在 Execute() 内部处理或通过字段/回调暴露。否则调用者又得感知具体命令的签名，破坏解耦。

典型封装方式：

立即学习“go语言免费学习笔记（深入）”；

Receiver 实例作为字段嵌入命令结构体（组合优于继承）
必要参数在创建命令时传入并保存为字段（如 file string, timeout time.Duration）
避免在 Execute() 中再传参——那说明封装不完整

调用者（Invoker）如何做到完全不知晓 Receiver

Invoker 只依赖 Command 接口，不 import 任何具体 Receiver 包。它只做三件事：接收命令、排队、触发 Execute()。

type Invoker struct {
    commands []Command
}

func (i *Invoker) Add(cmd Command) {
    i.commands = append(i.commands, cmd)
}

func (i *Invoker) ExecuteAll() {
    for _, cmd := range i.commands {
        cmd.Execute()
    }
}

常见错误：

Invoker 直接调用 receiver.DoSomething(...) —— 这根本不是命令模式，只是普通函数调用
Invoker 根据命令类型做 switch cmd.(type) 分支处理 —— 又把逻辑拉回调用侧，违背解耦初衷
把 Invoker 设计成单例或全局变量 —— 难以测试，状态易污染

Undo / Redo 支持必须靠命令自己保存上下文

Go 没有自动栈帧或反射式状态快照，Undo() 能否实现，完全取决于命令是否在 Execute() 前主动记录了足够信息。

比如文件重命名命令：

type RenameCommand struct {
    fs      FileSystem // 接口，便于 mock
    oldName string
    newName string
    // Undo 所需：执行前确认 oldName 存在，并记录原始状态（如 FileInfo）
    originalInfo os.FileInfo
}

func (r *RenameCommand) Execute() error {
    info, err := r.fs.Stat(r.oldName)
    if err != nil {
        return err
    }
    r.originalInfo = info // 保存用于 Undo
    return r.fs.Rename(r.oldName, r.newName)
}

func (r *RenameCommand) Undo() error {
    return r.fs.Rename(r.newName, r.oldName)
}

重点：