设计模式 - 命令模式

  我们先来分析一种常见的现象，我们都开关可以通过通过电线控制灯的开关，也可以更换电线控制门的开关等等此类的现象。仔细分析此类现象不难发现，我们想控制什么样的东西只需要更换相关的电线（可能不同的电器有自己相配套的电线标准），然后连接到同一个开关上既可以实现功能。如果我们把开关理解为消息请求者，把各种电器理解为不同的请求处理着，当请求者需要控制不同的请求处理着的时候，只需要更换电线，对于请求者自身不需要做任何的更改。联系我们的软件开发系统，不难发现有很多类似的现象模式。

来分析一个案例，一套系统可以灵活的给按钮配置不同的事件，当点击按钮的时候可以触发配置的对应物体的时间，如打开帮助文档，关闭窗口。我们知道，不同物体他的动作也是不同的，对于程序来说就是有不同的方法，因为按钮只有一个，对于按钮本身来说也只有一个动作事件，如果我们直接用按钮控制不同的物体，在此需要说明一下，要想用一个问题控制另外一个物体，对于程序来说必须彼此拥有对方的对象，这也是面向对象的设计理念，这样才可以调用不同对象的动作。假设我们用按钮引用物体的对象，然后调用A对象的动作时间，可是此时如果我们想更该另外一种物体对象，那么这个物体的动作也会有变化，这样我们就要更改按钮对象里面的代码，要更该成现在的对象引用，还要调用现在的对象的方法。这样违背了软件设计的闭合原则，而且扩展性很不好。联系现实情况，我们可以把按钮理解为请求发送者，也就是开关这个物体。首先来分析开关，对于开关来说，你无论换什么线，开关自身都不发生一点改变，他只知道开或者关，你连接什么线，我不关。在此中情况下，我们引入电线的处理着，他负责接受请求并发发送请求。这样可以把按钮可以物体之间结耦合。对于电线，不同的电线对应不同的物体，我们只需要写出不同的电线类，然后让他引用自身的物体，这点可以容易实现，但是问题来了，对于开关来说，我们总不能换一个电线，就把电线的对象注入到按钮里面吧，这样和最初的不引入电线概念没有任何区别。我们在仔细分析显示情况，对于开关来说，他其实只知道你是电线，而不知道你什么样品种的电线，如果这样来说，我们可以设想，我们是否可以引入一种东西这种东西他就是电线的抽闲概括，这样我们可以在按钮里面引用这个对象，自此我们可以联想到抽象类或者父类，因此我们可以写抽象类，然后让这些代理电线继承抽象类，另外，对于按钮来说，理想状态我们不更改任何的状态，也就是按钮里面执行一个动作就代表是发出了请求，因为我们此时已经把抽象类注入了，所以只要再执行抽象类的方法，这样就可以完成不修改代码，继而完成所有的功能。当然，此时如果需要添加新的功能，只需要继承抽象类，然后实现方法， 同时可以利用配置文件，到时候只需要更改配置文件，就可以完成一切功能。

这就是命令模式的设计理念，通过中间对象封装请求和处理请求，完成命令模式的设计。总结一下， 任何两个事物发生关系，有联系，其实就是彼此应用对方的对象，可以依赖注入也可以构造注入，注意针对抽象类编程的引用。