要资料 文章 文库 视频 Code iProcess 课程 认证 咨询 工具 火云堂 讲座吧   成长之路  
会员   
 
  
每天15篇文章
不仅获得谋生技能
更可以追随信仰
 
 
     
   
分享到
重构到模式系列-重构到Bridge模式
 

作者:横刀天笑,发布于2012-1-13

 

前言

在这篇文章中,我将以记述我整个重构过程的方式来得到桥接模式,也许很多人学习设计模式都有我这样的历程,看过很多模式的书籍,但还是无从下手,很多人都说模式往往是重构得来的,但是如何重构?如何去思考?

在这个设计模式初学者系列里我将改变以前的风格,今后每一篇都以真实的项目重构例子来描述重构到模式,所有的描述都来源于现实,如果没有现实的案例那我宁愿不写。希望以这种方式记录能够给一些像我一样曾经很困惑的朋友帮助。

背景

PM:小Y,你看,这个Dundas的Chart(注1)控件效果很好,功能也很强大,但是使用的时候太麻烦了,你能不能将其封装一下,这样其他人使用的时候也简单多了

我:嗯,这个我看看吧,应该可以。

注1

Dundas Chart控件是一个既可以用在WinForm里又可以用在WebForm里的图表控件,可以绘制各种曲线图、柱状图和饼图等等,功能十分强大。在本文中我们要了解Dundas Chart的三个概念:Chart、ChartArea、Series

如是我拿起纸和笔去收集需求:

A:这个我觉得当这个控件上的一个Series的Enabled属性值变化的时候应该触发一个事件,这样我们就可以在这个事件触发时干些事情了,但是现在没有,我不得不做很多工作

B:和A一样的问题,我觉得控件上一个ChartArea的Visible属性值变化时也应该触发一个事件。

C: ………

我的头慢慢的大起来,需求收集了一大堆,怎么弄呢?我还是做了下面这样的个设计

第一次重构:使用继承封装Chart原生API,使其更好使用

我相信很多人第一个设计也许是这样,一下子就想到继承,这样我们可以复用Dundas Chart里面的很多东西了,以免重写很多东西。

下面只选取一段Code:

public class JurassicSeries : Series

{

    //...更多扩展

    public event EventHandler<EventArgs> SeriesEnabled;

     protected void OnSeriesEnabled()

    {

         if (SeriesEnabled != null)

         SeriesEnabled(this, new EventArgs());

    }

    public new bool Enabled

    {

        get { return base.Enabled; }

    set {

             base.Enabled = value;

             OnSeriesEnabled();

        }

    }

    //.....更多扩展

}

使用继承扩展Series后,我们终于有了这个事件了,但是因为Dundas并没有将他们的一些属性加上virtual,没办法,我只好在这些属性前加上new了,看着总是挺别扭。然后我将新的控件发布给项目组成员,大家都很高兴,几乎不需要改什么代码就可以享受到更好的“服务”了。

但是问题也接着而来

A:使用你这个控件后,我将控件上的内容保存为xml的时候怎么和原来的xml模板不再一样了啊,而且有的时候还老出现一些怪异行为,控件好像工作的不怎么稳定

原来Dundas的保存xml文件功能是通过反射将属性一个个作为XmlNode的Attribute,在我扩展的时候我给控件添加了一些属性,这样保存的XML文件当然不同了,而且由于使用了继承这种白箱复用机制,有的地方改变了控件的默认行为,所以带来控件工作不稳定,怎么办?看来继承也不是灵丹妙药,我不得不再一次陷入思考,寻找别的良方。

这时大部分开发者耳旁肯定响起了这句话:优先使用组合而不是继承。是的,当时我的耳旁也响起了这句OO原则之一:

优先使用组合而不是继承

思考了下,我又做出了这种设计

第二次重构:使用组合而不是继承

没有再使用继承,我们把Dundas的Chart和Series当作一个黑盒子来复用,还是选取一段代码看看:

public class JurassicChart : UserControl

{

    //..................

    private Chart Chart;

    private IList<JurassicSeries> _series;

    public IList<JurassicSeries> Series

    {

        get { return this._series; }

    }

    public JurassicChart()

    {

        this.Chart = new Chart();

    }

    //.................

}

public class JurassicSeries

{

    //...更多扩展

    public event EventHandler<EventArgs> SeriesEnabled;

    protected void OnSeriesEnabled()

    {

        if (SeriesEnabled != null)

        SeriesEnabled(this, new EventArgs());

    }

    private Series Series;

    public JurassicSeries(Series series)

    {

        this.Series = series;

    }

    public bool Enabled

    {

        get { return this.Series.Enabled; }

        set {

            this.Series.Enabled = value;

            OnSeriesEnabled();

        }

    }

    //.....更多扩展

}

由于我们对Chart的扩展是黑盒进行的,所以无需担心我们更改了Chart控件的默认行为,为了使用方便,可以很快的过渡过来,我封装的时候提供的API和原来的控件的API一模一样,现在的实现只是在原来的API上附加了些东西:

这是一个什么模式呢?

好像是装饰者模式吧,我记得装饰者模式也是给对象添加职责的,不过装饰者模式是动态的给对象添加职责,你看这个能动态的添加职责么?那这个是什么模式呢?我也不知道-_-。

我将重新封装好的控件说明发给大家,然后将代码签入到TFS,由于API的兼容性,很快项目里面的Chart都迁移过来了,经过几天的使用不断的完善控件,功能也趋于稳定了。我想也许可以告一段落了。不过软件里面永恒不变的还是变化。

一天, PM开完会回来:

PM:小Y,刚才会上,公司的图形平台部展示了一下他们的成果,可能我们以后开发中图形控件将要使用公司的,毕竟是我们自己的,定制起来要简单些,但是我也看到了,他们的那些控件还处于研发阶段,还远远没有达到产品的要求,所以你能不能做出这样的设计,当我们的图形平台稳定后能快速的迁移到那个上面,但是我们也不能完全依赖那个,如果那个不成功的话我们还可以使用Dundas的这个。

我:这个。。。。

PM:应该是可以的,你下去想想。哦,还有一点,这个控件的样式要求既可以从Xml文件加载也可以编程实现,控件的数据要求既可以从数据库获取数据绑定或从Xml文件加载,但是图形平台的那个控件只能从Xml加载,所以在从数据库加载的时候你要自己处理一下

我:…………………..

哎,刚做完一个满意的设计,又要修改了。

现在的需求是,我们封装的控件可能有两种实现,Dundas和我们自己的图形平台,还要求有两种模式,Xml模式和数据库模式。貌似可以这样做个设计:

好深的继承层次啊,好像还能满足需求,还是先仔细想想,免得又要返工。

如果又有一种新的控件需要添加进来呢呢?比如图形平台的控件在发布的时候修改了一些接口,这样我们完全可以把它当作一个新控件添加进来,那么我们就需要添加两个类,或者在XmlChart,DataBaseChart这个地方我们添加一个类:控件样式从Xml模板加载,数据从数据库加载(这实际上是我们的常规做法),那么我还要新增两个类,看到没?每次变化类的数目都是以乘法增加。而且很不灵活,Chart的实现都依赖于相应的控件。但是经过这样一分析思路也更明确了,我们要的是两种模式的控件:Xml和数据库模式。但是这两种模式的控件不能知晓到底是依靠哪种第三方控件实现的,那我们只好把第三方控件放在接口后面”躲起来”,将两种模式和实现他们的控件之间解耦,这样各自才可能相互不依赖,可以独自的去变化。

第三次重构:重构到桥接模式

GOF:桥接模式的意图是将抽象与其实现解耦,使它们都可以各自独立的变化

这里的JurassicChart就是我们的抽象,我们使用Dundas’s Chart或者Ours JChart来实现这个JurassicChart,使用IChart这个接口来隔离抽象和变化,现在XmlChart和DataBaseChart对使用何种第三方控件实现毫不知情,让他们都可以按照自己的意愿独立的变化而相互不影响,当然,这个IChart接口肯定不能是随意变化的(一般来讲接口都是需要稳定的,如果接口不能稳定那你的设计明显有问题)

上面是设计的类图,详细的代码先有各位读者自己实现了,或许有一天我公开我的源码,不过几率不大,还是自己写下吧。想想,在你们自己的项目中是否有类似的需求?

后记

这篇文章来源于我真实的开发中,整个重构过程比文章中的更繁琐,写的比较啰嗦,希望能起到抛砖引玉。

从去年开始写一个设计模式初学者系列,写到第六篇了,无奈再也写不下去了,后来检查了下原因,还是那些模式并没有在真实项目中使用过,所以也无法描述,凭空想象的一些例子难免陷入泛泛而谈。所以今后我将改变原来的风格,以真实项目中重构的时间顺序记述下整个模式演化的过程。


相关文章

阻碍使用企业架构的原因及克服方法
世界级企业架构的行业挑战
企业架构和SOA架构的角色将融合
什么最适合您的组织?
相关文档

企业架构与ITIL
企业架构框架
Zachman企业架构框架简介
企业架构让SOA落地
相关课程

企业架构设计
软件架构案例分析和最佳实践
嵌入式软件架构设计—高级实践
企业级SOA架构实践
 
分享到
 
 
     


重构-使代码更简洁优美
Visitor Parttern
由表及里看模式
设计模式随笔系列
深入浅出设计模式-介绍
.NET中的设计模式
更多...   

相关培训课程

J2EE设计模式和性能调优
应用模式设计Java企业级应用
设计模式原理与应用
J2EE设计模式指南
单元测试+重构+设计模式
设计模式及其CSharp实现


某电力公司 设计模式原理
蓝拓扑 设计模式原理及应用
卫星导航 UML & OOAD
汤森路透研发中心 UML& OOAD
中达电通 设计模式原理
西门子 嵌入式设计模式
更多...   
 
 
 
 
 
每天2个文档/视频
扫描微信二维码订阅
订阅技术月刊
获得每月300个技术资源
 
 

关于我们 | 联系我们 | 京ICP备10020922号 京公海网安备110108001071号