1700483379
把小男孩原子弹修改为胖子号原子弹
1700483380
1700483381
贵族处理事件：胖子号原子弹修改，事件类型=EDIT_PRODUCT
1700483382
1700483383
=====模拟克隆产品事件========
1700483384
1700483385
克隆胖子号原子弹
1700483386
1700483387
贵族处理事件：胖子号原子弹克隆，事件类型=CLONE_PRODUCT
1700483388
1700483389
=====模拟销毁产品事件========
1700483390
1700483391
遗弃胖子号原子弹
1700483392
1700483393
乞丐处理事件：胖子号原子弹销毁，事件类型=DEL_PRODUCT
1700483394
1700483395
我们的事件处理框架已经生效了，有行为，就产生事件，并有处理事件的处理者，并且这三者都相互解耦，可以独立地扩展下去。比如，想增加处理者，没有问题，建立一个类继承EventCustomer，然后注册到EventDispatch上，就可以进行处理事件了；想扩展产品，没问题？需要稍稍修改一下，首先抽取出产品和事件的抽象类，然后再进行扩展即可。
1700483396
1700483397
1700483398
1700483399
1700483401
设计模式之禅 36.2 混编小结
1700483402
1700483403
该事件触发框架结构清晰，扩展性好，读者可以进行抽象化处理后应用于实际开发中。我们回头看看在这个案例中使用了哪些设计模式。
1700483404
1700483405
❑工厂方法模式
1700483406
1700483407
负责产生产品对象，方便产品的修改和扩展，并且实现了产品和工厂的紧耦合，避免产品随意被创建而无触发事件的情况发生。
1700483408
1700483409
❑桥梁模式
1700483410
1700483411
在产品和事件两个对象的关系中我们使用了桥梁模式，如此设计后，两者都可以自由地扩展（前提是需要抽取抽象化）而不会破坏原有的封装。
1700483412
1700483413
❑观察者模式
1700483414
1700483415
观察者模式解决了事件如何通知处理者的问题，而且观察者模式还有一个优点是可以有多个观察者，也就是我们的架构是可以有多层级、多分类的处理者。想重新扩展一个新类型（新接口）的观察者？没有问题，扩展ProductEvent即可。
1700483416
1700483417
❑中介者模式
1700483418
1700483419
事件有了，处理者也有了，这些都会发生变化，并且处理者之间也有耦合关系，中介者则可以完美地处理这些复杂的关系。
1700483420
1700483421
我们再来思考一下，如果我们要扩展这个框架，可能还会用到什么模式？首先是责任链模式，它可以帮助我们解决一个处理者处理多个事件的问题；其次是模板方法模式，处理者的启用、停用等等，都可以通过模板方法模式来实现；再次是装饰模式，事件的包装、处理者功能的强化都会用到装饰模式。当然了，我们还可能用到其他的模式，只要能够很好地解决我们的困境，那就好好使用吧，这也是我们学习设计模式的目的。
1700483422
1700483423
1700483424
1700483425
1700483427
设计模式之禅 第37章 规格模式
1700483428
[
上一页 ]
[ :1.700483379e+09 ]
[
下一页 ]