知识卡片
实践中应封装Receiver减少高层模块对它的依赖
内容
[[命令模式的定义与三个角色]]的通用类图里Client创建Command需显式传入Receiver，让高层 依赖了低层。实际项目更推荐把Receiver封装进Command内部：构造函数直接new出默认Receiver， 保留可传参覆盖的重载构造函数备用。发散：这是教科书图和实际工程写法的常见出入——落地时 往往把非必要暴露的依赖收进构造函数，用命名约定弥补省略的可读性。
参考来源
- 位置：《设计模式之禅（第2版）》第15章《命令模式》（源文件：_epub-src/text/part0071.html）
- 结论依据：原文指出通用类图中Client对Receiver的依赖在实际项目中通常会被封装掉，"每一个命令是对一个或多个Receiver的封装，我们可以在项目中通过有意义的类名或命令名处理命令角色和接收者角色的耦合关系……减少高层模块（Client类）对低层模块（Receiver角色类）的依赖关系"，并给出Command构造函数内部默认绑定Receiver的实现。
- 原始内容：命令模式的Receiver在实际应用中一般都会被封装掉（除非非常必要，例如撤销处理）……我们可以在项目中通过有意义的类名或命令名处理命令角色和接收者角色的耦合关系（这就是约定），减少高层模块（Client类）对低层模块（Receiver角色类）的依赖关系。