如何使用设计模式来构造系统--(7)

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

 

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

 

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

 

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

 

2.类图:

 

 

3.代码

 

首先封装创建过程:

public abstract class CompositeBuilder   //封装创建过程
{
    public abstract PersonComposite BuildComposite();
}

public class Builder:CompositeBuilder  //实现具体的创建过程
{
    public override PersonComposite BuildComposite()  
    {
        PersonComposite root = new PersonComposite();
        StaffAndSalaryFactory saf = new StaffAndSalaryFactory();  //实例化工厂
        for (int j = 0; j < 5;j++ )
        {
            PersonComposite pc = new PersonComposite();
            pc.Name = j.ToString();
            for (int i = 0; i < 10; i++)
            {
                AbstractPerson staff = saf.GetPerson();  //创建员工
                staff.PersonName = "  涵舍愚人"+j.ToString()+i.ToString();
                staff.PersonSalary = saf.GetSalary();//创建员工工资
                if (i % 2 == 0)
                {
                    staff.PersonSalary.Salaryprize = BadPrize.badPrize;//使用单件初始化员工工资的绩效部分
                    //该员工工资为：6000+绩效3000=9000
                }
               else
                {
                    staff.PersonSalary.Salaryprize = GoodPrize.goodPrize;//使用单件初始化员工工资的绩效部分
                    //该员工工资为：6000+绩效6000=12000
                }
                pc.AddComposite(staff);//将Staff加到部门PC
            }
            root.Composite.Add(pc);
        }
        return root;
    }
}

 

 

封装创建:

public class Director  //封装创建
{
    public PersonComposite GetPersonComposite(CompositeBuilder cb)
    {
         return cb.BuildComposite();
    }
}

 

客户代码:

 

class Program
    {
        static void Main(string[] args)
        {
            Builder b = new Builder(); //实例化具体Builder
            Director d = new Director();  //实例化Composite的创建
            PersonComposite pc = d.GetPersonComposite(b);  //用d对象的固定方法创建PersonComposite
            Print(pc); //调用输出
            Console.Read();
        }
        public static void Print(PersonComposite pc)
        {
            Listterator list = new Listterator(pc);  //实例化一个遍历器,用来遍历Composite的子节点
            while (list.Next())  //遍历下一个节点
            {
                PersonComposite spc = list.Current() as PersonComposite;//如果是部门,输出部门名字
                if (!Equals(spc, null))
                {
                    Console.Write("部门"+spc.Name+"\r\n");  
                    Print(spc); //如果是部门,则递归
                }
                else
                {
                    AbstractPerson ap = list.Current() as AbstractPerson;  //如果是人员,输出人员和工资
                    if (!Equals(ap, null))
                    {
                        Console.Write(ap.PersonName + "应得工资为" + ap.GetShouldpaid().ToString()+"\r\n");
                    }
                }

            }
        }
    }

 

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

 

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

 

输出结果:

 

 

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

 

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

 

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