(声明:本系列所用的模式都来自GOF23中,本系列并不是讲23种经典设计模式,而是如何去使用这些模式)   

 

在前面的文章中,我们设计完成了员工工资,福利以及按照部门来区分员工,以及遍历统计部门人员成本等业务逻辑,这些设计基本上可以满足我们所设定的场景的变化,可是创建部门及人员树的时候太复杂了,而且这种创建很容易发生变化,比如加入分公司,或者部门层级变动添加了层级的时候,创建的代码一定就要修改.那么如何避免,封装这个创建时的变化呢?

 

1.分析:来看看我们的意图,我们要将复杂的部门创建过程封装,使得同样的构建过程可以创建不同的部门.那么我们就需要把创建单独封装,创建的过程也需要单独封装.

 

Gof23中的Builder(生成器)模式:将一个复杂对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示。 与我们的意图相符.那么我们就来使用Builder模式.

 

2.类图:

 

 

3.代码

 

首先封装创建过程:

Code

 

 

封装创建:

Code

 

客户代码:

 

Code

 

我们现在把创建过程封装在了Build类里,当然这里可以是多个步骤,比如创建部门,创建组,创建人员等.

 

将创建完成Composite放到了Director类的固定方法中,我们可以先创建部门,然后组,再然后人员,甚至可以反过来,这样创建过程不变,而Director的GetPersonComposite方法的创建步骤不同,就可以创建出不同的树.这样即使需求变化了,客户代码也不需要去改变,只要去创建不同的Builder和修改Director的方法就好了,如果Director用工厂方法来做,那么连它都不需要修改,而直接添加就好了,设计模式的原则之一就是添加优于修改.

 

输出结果:

 

 

在创建时,给人员名字前加了个空格,就出现了一个简单的树,如果要写树,可以用我们前面用过的Stratege,来封装树控件前面的那小加号,减号,竖线等,然后在创建中使用这些封装的策略.就OK了

 

这样我们就完成了复杂的Composite的创建的封装,但是这里面还有缺点:前面我们说了一个人可能身兼二职,尤其管理层的,更有这个可能,那么他就要出现在不同部门里,而我们现在的创建是一个节点一个对象,这样我们就要浪费内存了...怎么解决?下一篇中我们将介绍!

 

    下一篇:如何使用设计模式来构造系统--(8)

 

posted on 2008-08-20 14:52  徐 磊  阅读(2596)  评论(13编辑  收藏  举报