打字猴:1.7004829e+09
1700482900 public class EventDispatch implements Observer{
1700482901
1700482902 //单例模式
1700482903
1700482904 private final static EventDispatch dispatch=new EventDispatch();
1700482905
1700482906 //不允许生成新的实例
1700482907
1700482908 private EventDispatch(){
1700482909
1700482910 }
1700482911
1700482912 //获得单例对象
1700482913
1700482914 public static EventDispatch getEventDispathc(){
1700482915
1700482916 return dispatch;
1700482917
1700482918 }
1700482919
1700482920 //事件触发
1700482921
1700482922 public void update(Observable o,Object arg){
1700482923
1700482924 }
1700482925
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 //首先修改权限,允许创建
[ 上一页 ]  [ :1.7004829e+09 ]  [ 下一页 ]