1700482926
}
1700482927
1700482928
产品和事件都定义出来了，那我们想想怎么把这两者关联起来，产品和事件是两个独立的对象，两者都可以独立地扩展，用什么来适应它们的扩展呢？桥梁模式！两个不相关的类可以通过桥梁模式组合出稳定、健壮的结构，我们画出类图，如图36-3所示。
1700482929
1700482930
1700482931
1700482932
1700482933
图36-3 桥梁模式实现产品和事件的组合
1700482934
1700482935
看着不像桥梁模式？看看桥梁模式的通用类图，然后把抽象化角色和实现化角色去掉看看，是不是就是一样了？各位可能要说了，把抽象化角色和实现化角色去掉，那桥梁模式在抽象层次耦合的优点还怎么体现呢？因为我们采用的是单个产品对象，没有必要进行抽象化处理，读者若要按照该框架做扩展开发，该部分是肯定需要抽象出接口或抽象类的，好在也非常简单，只要抽取一下就可以了。这样考虑后，我们的ProductManager类就增加一个功能：组合产品类和事件类，产生有意义的产品事件，如代码清单36-6所示。
1700482936
1700482937
代码清单36-6 修正后的产品工厂类
1700482938
1700482939
public class ProductManager{
1700482940
1700482941
//是否可以创建一个产品
1700482942
1700482943
private boolean isPermittedCreate=false；
1700482944
1700482945
//建立一个产品
1700482946
1700482947
public Product createProduct（String name）{
1700482948
1700482949
//首先修改权限，允许创建
1700482950
1700482951
isPermittedCreate=true；
1700482952
1700482953
Product p=new Product（this,name）；
1700482954
1700482955
//产生一个创建事件
1700482956
1700482957
new ProductEvent（p,ProductEventType.NEW_PRODUCT）；
1700482958
1700482959
return p；
1700482960
1700482961
}
1700482962
1700482963
//废弃一个产品
1700482964
1700482965
public void abandonProduct（Product p）{
1700482966
1700482967
//销毁一个产品，例如删除数据库记录
1700482968
1700482969
//产生删除事件
1700482970
1700482971
new ProductEvent（p,ProductEventType.DEL_PRODUCT）；
1700482972
1700482973
p=null；
1700482974
1700482975
}