本文意在分享自己理解的命令模式，尽量生动有趣，本文将使用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
最后，没有什么设计模式是最好的，只有最好的使用方法