本篇博客记录了我在工作过程中的一个设计单元。
需求
图1 界面原型
用户可以指定对对象的某属性进行某个比较操作。
设计-总体结构
图2 总体结构
看上去会有点晕？懒了一点，就全画一起了。 :o)
中间的接口就是整个结构的核心所在，下面会详细解释：
第一组接口：设计匹配概念
首先，明确匹配的概念，这个概念是与gix4应用无关的。 一个是可以被匹配的对象，另一个则是主动匹配者。如下：
第二组接口：设计过滤规则
动态规则是需要存储到数据库中的，但是由于它的形式十分灵活，所以这里选用xml这种半结构化的数据格式来存储规则内容，最后再序列化存储到数据库中。这种解决方法适用于一些小型的、结构变化性大的对象，如下：
ifilterrule是这三个中最重要的接口。表示一个动态的过滤规则。在gix4中，它可以是一个简单的规则：
“对象的name属性应该包含‘***’”
也可以是由各种简单规则复合而成，如：
“对象的name属性应该包含‘***’” and “对象的name属性应该满足正则表达式‘***’” and “对象的amount属性应该大于‘0’”
这里ifilterrule接口及其子类的设计方法，类型“表达式树”。（朋友说其实是解释器模式，不过我自己也没记住解释器模式是什么结构，所以不知道这里到底是不是。） :o)
第三组接口：元数据-比较操作
过滤的规则是动态的，但是对于某种数据类型（string、int）进行的比较操作，却是固定的。过滤规则则是由这些固定的操作组合而成。如：我可以对user对象的name属性（string）进行是否以某字符串开头的判断，可以定义如下：name beginwith “王”，这里的beginwith就是一个比较操作，它针对类型string。操作定义如下：
第三组接口：元数据-属性规则
由于项目中最常使用的就是根据属性的值来进行简单的过滤，所以定义了一个“可匹配属性”接口。通过它，可以获得能够对这个属性进行的所有操作。可以获取到指定的可匹配对象imatchable的该属性值。实现时可以不使用反射而进行快速获取值，加快匹配速度。
到现在，最基本的接口就已经设计完成。
集成到gix4
1.外观
模块使用外观模式构建facade类来降低外部使用的复杂度。
2.组装
系统主要是匹配pbs到fgqbqitem。本着“新增优于修改”的原则，不想在原有的类上修改或者、添加新的代码，所以这里为这两个类分别扩充新类fgqbqitemmatch和pbsmatchtarget，并实现imatchable和imatchtarget，然后再由实现imatchable的类fgqbqitemmatch指定哪此属性（fgqbqitemmatchproperty类）可以用于匹配就行了，如下图：
图3 集成过程
其它-界面
有意思的是，由于这次的界面是动态的，实现过程中使用了装饰模式以重用属性规则编辑器。图就不画了，贴下代码图：
图4 界面代码
最后的界面如下：
图5 最终界面
其它-所有代码图
除了界面以外，整个方案的代码图如下：
图6 所有代码
后话
做完了，感觉解决得还行。原来发的文章都没什么人搭理，这次真心希望多来几个拍砖的，没人说，就没进步啊。嘿嘿。
另外，cnblog没有多大的空间传文件，所以就不传代码了。如有谁需要代码，可以留言找我。