命令模式1

命令模式是一种行为设计模式，它的主要作用是将一个请求封装为一个对象，使得发送者和接收者解耦，使得请求本身成为一个对象。这样做的好处是可以对请求进行参数化，可以将请求排队、记录请求日志，甚至支持撤销或重做操作。 在JavaScript中，我们可以看到一个简单的例子，即车辆购买程序。原本的`CarManager`对象包含了三个方法：`requestInfo`、`buyVehicle`和`arrangeViewing`，它们分别对应了查询车辆信息、购买车辆和安排看车的业务逻辑。这些方法直接在`CarManager`对象上执行，这导致了对象之间紧密的耦合。 为了遵循命令模式，我们需要将这些操作封装成独立的命令对象。我们创建了一个`execute`方法在`CarManager`对象上，它接收一个包含`commandType`、`model`和`carID`的参数对象。`execute`方法根据`commandType`动态调用相应的操作，实现了对原始方法的间接调用，降低了对象之间的耦合度。 改造后的`CarManager.execute`方法如下： ```javascript CarManager.execute = function (command) { return CarManager[command.request](command.model, command.carID); }; ``` 通过这种方式，我们可以用以下方式执行各种操作： ```javascript CarManager.execute({ request: "arrangeViewing", model: 'Ferrari', carID: '145523' }); CarManager.execute({ request: "requestInfo", model: 'Ford Mondeo', carID: '543434' }); // ... 其他命令 ``` 命令模式的其他优点包括： 1. **可扩展性**：添加新的命令只需要创建新的具体命令类，而无需修改原有代码。 2. **可撤销操作**：可以通过维护一个命令的历史记录，实现撤销或重做功能。 3. **易于设计命令队列**：可以将多个命令放入队列中顺序执行，或者异步执行。 4. **灵活性**：接收者可以根据需要决定何时执行命令，甚至不执行。 然而，命令模式并非总是必要的。在敏捷开发的原则下，我们应当避免过度设计。如果在早期阶段无法确定需求，不应该盲目地引入命令模式。只有当确实有需求，比如需要记录操作历史、支持撤销/重做或命令调度时，才考虑使用命令模式。实际上，随着需求的明确，我们可以在后期通过重构来引入命令模式，而不会对系统造成太大影响。