白话设计模式--实践应用--template method,factory和facade模式

在设计模式的学习过程中，有时候我觉着特别郁闷。因为有时候看过书了吧，觉得自己懂了。回头过来，自己想想，又忘了。这事儿闹的，白忙乎了。

现在尝试一些新的学习方法，把在工作中遇到的实际项目中用到的设计模式写下来，通过更多的实践和思考来深入学习设计模式。

今天就说一个最近用到的小实践，其中包括了facede,factory和template method.

 

因为要给客户做个MIS系统，所以要用到很多business form(report).要求在一个entity创建完了之后，就直接可以打印出来一个business form。

我们使用了crystalreport V11,定义一个dataset的schema，然后通过后台把数据传给business form并打印出来。我不想详细的说这个过程，因为那不是本文的重点。我想说的是这其中使用到的一些设计模式和技巧。

因为business form有很多种，比如工作单啊 评估单啊 审批单啊等等啦，根据不同的业务有不同的form。在这里首先使用了facade模式，打印操作只针对这一个facade,别的前台并不关心，只需要给facade一些打印必须的参数就可以了，比如说对应的entity，打印（机）信息等等。

facade模式是最简单的几种设计模式之一，今天我们就说最简单的。呵呵。

一个管理系统很可能有很多个business form,这些form都有一些共同点，比如说都要生成一个report，都要从某处取得数据，都要进行打印动作等等。因为有很多共同的抽象动作，而每个form的具体行为并不相同（大家各取各自的数据，有的可能有子报表，有的可能没有等等），所以可以抽象出来一个抽象类，暂且叫做BusinessForm,这个抽象类就定义了一系列的行为，并实现了其中的一些，比如打印，设置子报表数据源等等。而定义了一些抽象方法，比如GetData，GetReport，是不是包含子报表等等。现在当需要一个工作单的时候，我们就让这个工作单类继承BusinessForm,然后实现自己的取数据的方法，实现自己的取报表方法等等。 

最后，我们还需要一个简单工厂来创建每个business form类（上面提到的，具体实现逻辑的类），通过传入的business form的name或者其他标识，创建一个business form的实现类，而BusinessForm是它们的父类，也就是模板。大家都按照这个模板来实现自己的东西，最后通过工厂来创建，通过facade来使用。这个工厂是一个普通类，里面只有一个静态方法：GetBusinessForm,传入一个字符串（name），返回一个BusinessForm抽象类。简单类图如下：

 

     东西简单，希望对大家有帮助，欢迎拍砖，也希望大家把自己项目中用到的实践拿出来分享，共同进步。谢谢。

     刚在网上闲逛，看了篇模板方法模式的文章，又想起这个项目里的一些东西。

     在数据访问层，每个DataAccessObject都集成自一个抽象的DAO对象，这也应该算是模板方法吧？其它层也有可能抽象出一些东西，比如WEB层，如果每个页面都要做一些一样的事情，是不是也可以抽象出一个叫做继承自 webpage的父页面类呢？

      看来设计模式无处不在，不是缺少美，而是缺少发现啊

      今天看了一篇关于模版方法模式的文章，觉得自己之前的理解还是少了一些东西，特地从床上爬起来记录一下。

      Template Method实际上是继承特性的一种应用，而策略模式是对委托的一种应用，在我看来，这两种模式很多时候是可以互相替换的。因为模版方法也是定义了一些算法，这就是我说的我之前没有感受到的。模版方法在抽象类中定义了一系列的抽象方法，注意，以及，以及，以及如何使用这些抽象方法的。通常，如何使用是不变化的，例如在这里，打印任何一个business form的过程都是一样的，不同的只是如何取得数据，把数据传送给哪个rpt以及使用哪个打印机。所以，这是一种算法，而实现的内容又子类决定，并且必须决定（抽象方法必须被实现），这样其实就跟策略模式应用的场景几乎一样了。  我非常想知道大家的想法，我这么理解是不是有问题呢？