虽然对于设计模式谈不上认识，但我希望能做成一件事，就是从今天开始将工作中应用设计模式所做的设计记录下来，也算是设计模式在应用过程中的总结，暂且不论对错。等到退休的时候，再来看看，将是另一种心情。

    先说说框架的一个工具，当时具体的需求是：需要做一个代码生成工具，可以从sqlserver中获取表结构，生成用于转换为ICE类的实体描述文件。（关于ICE，大家可以上网查查，不管是什么，反正就是要求生成一个特定格式文件）

    功能很简单，就是从sqlserver数据库中获取某个表的结构信息，让后根据表的结构生成项目开发种需要的文件，比如类文件，xml文件等等。做设计的时候，考虑的是对变化的封装。那我们来看看这个小小的工具会存在什么样的变化。第一，系统虽然目前使用的是sqlserver数据库，但需要考虑以后如果用Oracle或者其他数据库，那该如何是好。所以这个工具首先是要支持不同的数据库，保证在数据库变化的同时支持数据库类型的可扩展。 第二，虽然现在只要求生成ICE转换前的类文件，但以后也许还会有根据表结构生成xml描述文件也说不定，利用表结构生成不同的文件太普遍了，既然想到了，就需要支持生成不同的类型文件的扩展。不管以后怎么样，还是得留一些余地啊。暂时只想到了这两方面的变化，其他的没想到，以后再说吧。

    设计思路：这个工具目前考虑到的有两方面的变化，一个是数据库，另一个是不同类型文件。
    什么都不想，拍拍脑袋，最先使用肯定是类继承。可如果使用类的继承，那一旦数据库改为Oracle、MySql数据库，或者需要生成其他格式的文件，那么就要增加很多类，越往后，增加的越多，类就要泛滥了。简图：
   

    考虑了一下，于是选择了bridge模式。为什么？支持多唯变化，能够支持不同数据库和不同类型文件的改变。同时，为了能够使用统一格式的数据集，方便FileCreator按照统一的方式读取表结构信息，在FileCreator类中调用DataBase类型对象获取表结构数据集时统一转换为固定格式的表结构信息格式。（当然，实现统一格式方法很多，也可从数据库这级做文章。）通过这样的设计，如果数据库变了或者新增了一种文件格式，只需要新增一个数据库对应的类或者一个文件格式类，其他不用做任何改动。比上面的设计清爽多了。
        
    简图如下：

 
    好了，下次继续。