1700463135
pg.plan（）；
1700463136
1700463137
}
1700463138
1700463139
}
1700463140
1700463141
运行结果如下所示：
1700463142
1700463143
––––-客户要求删除一个页面–––––—
1700463144
1700463145
找到美工组……
1700463146
1700463147
客户要求删除一个页面……
1700463148
1700463149
客户要求页面变更计划……
1700463150
1700463151
好了，界面也谈过了，应该没什么大问题了吧。过了一天后，客户又让代码组过去，说是数据库设计问题，然后又叫美工组过去，布置了一堆命令……这个就不一一写了，大家应该能够体会得到！问题来了，我们修改可以，但是每次都是叫一个组去，布置个任务，然后出计划，每次都这样，如果让你当甲方，你烦不烦？而且这种方式很容易出错误，而且还真发生过。客户把美工叫过去了，要删除，可美工说需求是这么写的，然后客户又命令需求组过去，一次次地折腾之后，客户也烦躁了，于是直接抓住我这个项目经理说：“我不管你们内部怎么安排，你就给我找个接头负责人，我告诉他怎么做，删除页面，增加功能，你们内部怎么处理我不管，我就告诉他我要干什么就成了……”
1700463152
1700463153
我一听，好啊，这也正是我想要的，我项目组的兄弟们也已经受不了了，于是我改变了一下我的处理方式，如图15-2所示。
1700463154
1700463155
1700463156
1700463157
1700463158
图15-2 增加负责人后的类图
1700463159
1700463160
在原有的类图上增加了一个Invoker类，其作用是根据客户的命令安排不同的组员进行工作，例如客户说“界面上删除一条记录”，Invoker类接收到该String类型命令后，通知美工组PageGroup开始delete，然后再找到代码组CodeGroup后台不要存到数据库中，最后反馈给客户一个执行计划。这是一个挺好的方案，但是客户的命令是一个String类型的，这有非常多的变化，仅仅通过一个字符串来传递命令并不是一个非常好的方案，因为在系统设计中，字符串没有约束力，根据字符串判断相关的业务逻辑不是一个优秀的解决方案。那怎么才是一个优秀的方案呢？解决方案是：对客户发出的命令进行封装，每个命令是一个对象，避免客户、负责人、组员之间的交流误差，封装后的结果就是客户只要说一个命令，我的项目组就立刻开始启动，不用思考、解析命令字符串，如图15-3所示。
1700463161
1700463162
1700463163
1700463164
1700463165
图15-3 完美的类图
1700463166
1700463167
Command抽象类只有一个方法execute，其作用就是执行命令，子类非常坚决地实现该命令，与军队中类似，上级军官给士兵发布命令：爬上这个旗杆！然后士兵回答：Yes,Sir！完美的项目也与此类似，客户发送一个删除页面的命令，接头负责人Invoker接收到命令后，立刻执行DeletePageCommand的execute方法。对类图中增加的几个类说明如下：
1700463168
1700463169
Command抽象类：客户发给我们的命令，定义三个工作组的成员变量，供子类使用；定义一个抽象方法execute，由子类来实现。
1700463170
1700463171
Invoker实现类：项目接头负责人，setComand接收客户发给我们的命令，action方法是执行客户的命令（方法名写成是action，与command的execute区分开，避免混淆）。
1700463172
1700463173
其中，Command抽象类是整个扩展的核心，其源代码如代码清单15-7所示。
1700463174
1700463175
代码清单15-7 抽象命令类
1700463176
1700463177
public abstract class Command{
1700463178
1700463179
//把三个组都定义好，子类可以直接使用
1700463180
1700463181
protected RequirementGroup rg=new RequirementGroup（）；//需求组
1700463182
1700463183
protected PageGroup pg=new PageGroup（）；//美工组
1700463184