GOF模式之工厂，Adapter，模板，构建者模式---张逸《设计精要与模式》总结之一

    张逸的设计模式还是很有实践水平的，他会结合业务场景，指出为拟解决什么样的问题，而使用什么样的模式，其中的例子可以看出作者在实践方面有很深的造诣，不愧是微软出来的，崇拜之，学习之。之所以读这本书也是我同事极力推荐我的，我觉得他在架构方面还是不错的，他告诉我他设计模式方面也仅仅读过这一本书。
   准备写这样一个系列的博客，其中原有的一些例子，我觉得不够好，会自己修改下，也会有自己的心得体会，希望博友们支持探讨，废话少说，开始我们的模式之旅吧

   本回涉及的模式有四个，标题已经注明了：

1.应用场景：设计报表组件，支持水晶报表等
希望扩展：以后支持用友华表等。
分析：主要对象有报表对象—用于存储报表数据，报表格式对象--用于控制报表数据的显示格式，报表处理器对象—用于负责报表对象和报表处理器对象。

 

 

  

 

上面处理的问题，每次使用都要new Factory，采用静态类实现一个具体的Factory获取

  Public static class UtilManager{ Public static IreportFactory = new CellReportFactory(); } 

 

 

这种好处是，如果改变使用报表类型，只要修改一处就可以了。

 

 

小贴士：现在，使用哪个对象的问题早就由依赖注入解决了，但是这丝毫不影响abstractFatory 发挥他的作用，它的作用在与简化一系列对象的的创建，比如要创建三个对象，那就把他们作为一个对象组来创建，每次只要new 一个Factory 就可以了，可以转化为仅仅使用哪个factory的问题，而这个factory可以采用依赖注入的方式定义。抽象工厂用于创建一组对象，而工厂用于创建一个对象。

 

设计原则：对内部修改时开放的，对外部引用确定的，若非万不得已，不要修改已经提供的接口，这里所说的接口包含给别人用的任何类，而不仅仅限于系统间的接口，尽管系统间的接口更要考虑这个问题。

 

 

 

 

 

考虑业务变更，增加了一个需要创建别的对象的报表组件。
 

Adapter模式

 

 

Adapter Extends CrystalReportFactory implements IreportFactoryExtension

 
 

 

这样，原来的  IreportFactory factory = new CrystalReportFactoryAdapter (); 这个仍然成立

对外仍然是不变的。

唯一的缺点是需要强制类型转换才能使用

 

 

 

引申：考虑使用抽象还是使用接口,如何避免强制转化

使用模板模式+抽象工厂模式，共同的东西作为抽象工厂抽象方法，只有一个子类需要的作为实际的方法，需要的子类则覆盖这个方法，这样就避免了显式的转化。

小贴士： 什么时候用抽象类，什么时候用接口。

①子类中有共同的实现逻辑，选择抽象类。

②存在明显的多重继承的可能

③其它情况优先选择抽象类。

 

2.       应用场景：工厂设备 由Machine ，Port等组成。Port有入口类型input，和出口类型output有的设备是一个Machine 带有输入输出口，有的是一个设备是一个Machine带有输入输出口。

希望扩展:满足以后一个机器多个输入输出接口等的定义。

分析：设备类有设备名称等。Machine 类有名称等，Port类有输入输出口等。

 

糟糕的设计—调用时进行对象的组合，创建了Machine和N多port等对象，通过set方法组合起来。

 

 
 

使用builder模式

 

 

进阶，如何组装执行这些对象,需要一个导演类，这个导演类由Factory来承担（应用模式自如的时候自然会想到需要怎样的模式来组织过程，对于创建对象的一搬就是Factory模式了）

 

InputEQPBuilder builder = new InputEQPBuilder(); Equipment eqp = LCDFactory.createEQP(builder,“inputEQPBuilder”);