设计模式-命令模式

本文意在分享自己理解的命令模式，尽量生动有趣，本文将使用WPF为例子：

首先让我们想想一下，一个最简单的实现，按下遥控器，灯就亮了的逻辑

说干就干，手把手实现：

灯有开关两个行为

一个接口提供命令启动

根据传进来的实例实现Execute方法

把命令传进来

于是乎：

这样子好像和之前没什么不一样？

没事，不紧张，让我们想想，一个家里面肯定不止一个加点，现在，家具慢慢多起来了，情况开始复杂起来，我想一键启动所有的东西

让我们回顾下设计模式六大原则

单一职责原则（SRP）：灯，风扇，洗衣机好像啥都没干，遥控器帮他们全都干了，严重违反。

迪米特法则（LoD）：遥控器类好像和所有的实例对象都接触了，严重违反

不允许

改造下


在SetCommand的时候把让灯，风扇，洗衣机启动的命令传进来

继承ICommand，实现他的Execute就可以啦

这样的话就变成了

至此，一个简单的命令模式就完成了

在对照一下六大原则：

单一职责原则（SRP）：Light类 负责控制灯的开关操作，ICommand接口和具体的命令类负责封装开关操作的命令，SimpleRemote类负责管理命令并执行它们。每个类都只有一个明确的职责，符合SRP原则。

开放封闭原则（OCP）：通过定义ICommand接口和具体的命令类，可以方便地添加新的命令，而不需要修改已有的代码。SimpleRemote类可以通过添加新的命令来扩展功能，符合OCP原则。

里氏替换原则（LSP）：LightOnCommand和LightOffCommand类都实现了ICommand接口，可以替换ICommand类型的对象。这样，SimpleRemote类可以接收任何实现了ICommand接口的命令对象，符合LSP原则。

依赖倒置原则（DIP）：SimpleRemote类通过依赖ICommand接口而不是具体的命令类，实现了高层模块（SimpleRemote）依赖于抽象（ICommand）的设计。这样可以提高代码的灵活性和可维护性，符合DIP原则。

接口隔离原则（ISP）：除了ICommand没有其他接口

迪米特法则（LoD）：SimpleRemote类只与ICommand接口进行交互，而不需要了解具体的命令类的实现细节。这样可以降低类之间的耦合性，符合LoD原则。

Good

最后，没有什么设计模式是最好的，只有最好的使用方法