1700462241
1700462242
//库房管理人员管理库存
1700462243
1700462244
System.out.println（”\n––库房管理人员清库处理––—”）；
1700462245
1700462246
Stock stock=new Stock（）；
1700462247
1700462248
stock.clearStock（）；
1700462249
1700462250
}
1700462251
1700462252
}
1700462253
1700462254
我们在场景类中模拟了三种人员的活动：采购人员采购电脑，销售人员销售电脑，库管员管理库存。运行结果如下所示：
1700462255
1700462256
––采购人员采购电脑––—
1700462257
1700462258
IBM电脑的销售情况为：95
1700462259
1700462260
采购IBM电脑：100台
1700462261
1700462262
库存数量为：200
1700462263
1700462264
––销售人员销售电脑––—
1700462265
1700462266
销售IBM电脑1台
1700462267
1700462268
库存数量为：199
1700462269
1700462270
––库房管理人员清库处理––—
1700462271
1700462272
清理存货数量为：199
1700462273
1700462274
折价销售IBM电脑199台
1700462275
1700462276
不再采购IBM电脑
1700462277
1700462278
运行结果也是我们期望的，三个不同类型的参与者完成了各自的活动。你有没有发现这三个类是彼此关联的？每个类都与其他两个类产生了关联关系。迪米特法则认为“每个类只和朋友类交流”，这个朋友类并非越多越好，朋友类越多，耦合性越大，要想修改一个就得修改一片，这不是面向对象设计所期望的，况且这还是仅三个模块的情况，属于比较简单的一个小项目。我们把进销存扩展一下，如图14-3所示。
1700462279
1700462280
1700462281
1700462282
1700462283
图14-3 扩展后的进销存示意图
1700462284
1700462285
这是一个蜘蛛网的结构，别说是编写程序了，就是给人看估计也能让一大批人昏倒！每个对象都需要和其他几个对象交流，对象越多，每个对象要交流的成本也就越大了，只是维护这些对象的交流就能让一大批程序员望而却步！从这方面来说，我们已经发现设计的缺陷了，作为一个架构师，发现缺陷就要想办法修改。
1700462286
1700462287
大家都学过网络的基本知识，网络拓扑有三种类型：总线型、环型、星型。星型网络拓扑如图14-4所示。
1700462288
1700462289
1700462290