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

(由于篇幅有限，部分代码请看如何使用设计模式来构造系统--(1) )

上一篇我们分析了员工，工资，以及绩效奖金三个类，并且使用了Bridge和Stratege两种模式，对他们之间的组合和行为进行了设计，但是我们的设计并不完善。我们知道员工的基本工资可能每年都不一样，甚至有可能随时地根据公司的制度发生变化，而设计的根本意图就是去封装变化，让我们的系统更加的长寿，不会因为变化而大量的重造，我们怎么去避免工资变化时，员工类不改变呢？？

先看一下，上次设计的员工类的代码：



public abstract class AbstractPerson

{

protected string _personName; //员工姓名

protected Salary _personSalary; //员工工资

public string PersonName

{

get { return _personName; }

set { _personName = value; }

}

public Salary PersonSalary

{

get { return _personSalary; }

set { _personSalary = value; }

}

public abstract double GetShouldpaid(IPrize prize);

}

public class Staff : AbstractPerson

{

public override double GetShouldpaid(IPrize prize)

{

_personSalary = new SttafSalary(); //初始化正式员工的基本工资

_personSalary.Salaryprize = prize; //赋予绩效

return _personSalary.GetShouldpaid();

}

}

这里我们看到在初始化员工工资时出现了new SttafSalary(),这就使Person与SttafSalary产生了紧耦合，也就是说SttafSalary的变化会影响Person类的稳定。那么使用何种设计模式来封装这种创建时的变化呢？

GOF23中的Factory Method(工厂方法): 定义一个用于创建对象的接口，让子类决定实例化哪一个类。Factory Method 使一个类的实例化延迟到其子类。

工厂方法的意图和我们要封装的变化意图相同，那么我们就用它来设计吧，看看类图：



我们使用两个同接口的工厂来封装创建时的变化，这样你在各个工厂中去添加或修改你的业务都不会影响到Person，当然原来的那种直接new的方法也不会改变，但是当你的员工类包含的工资类发生变化时（比方说现在InterShip的工资升级为正式员工的工资，而正式员工的工资重新定义），就不能应对变化了，但是将创建工作封装到Factory，就可以避免这种变化引起的Person类的修改，而只需要去添加Salary的子类，修改Factory的子类，就可以完成了。

我们来看代码。

工厂部分的实现：



public abstract class SalaryFactory

{

public abstract Salary GetSalary(); //留给具体某种工资福利制度工厂去实现

}

public class StaffSalaryFactory:SalaryFactory

{

public override Salary GetSalary() //具体某种工资福利制度工厂

{

return new SttafSalary();

}

}

public class InternshipSalaryFactory:SalaryFactory

{

public override Salary GetSalary() //具体某种工资福利制度工厂

{

return new InternshipSalary();

}

}

Person类的实现：



public abstract class AbstractPerson

{

#region 字段

protected string _personName; //员工姓名

protected Salary _personSalary; //员工工资

#endregion

#region 属性

public string PersonName

{

get { return _personName; }

set { _personName = value; }

}

public Salary PersonSalary

{

get { return _personSalary; }

set { _personSalary = value; }

}

#endregion

public abstract double GetShouldpaid(IPrize prize);

}

public class Staff : AbstractPerson

{

public override double GetShouldpaid(IPrize prize)

{

_personSalary = new StaffSalaryFactory().GetSalary();

_personSalary.Salaryprize = prize;

return _personSalary.GetShouldpaid();

}

}

public class Internship : AbstractPerson

{

public override double GetShouldpaid(IPrize prize)

{

_personSalary = new InternshipSalaryFactory().GetSalary();

_personSalary.Salaryprize = prize;

return _personSalary.GetShouldpaid();

}

}

OK，这样我们就完成了这种变化的封装。在实际项目中你可以把Person中创建具体那个工厂，在配置文件中存储，然后做个Switch ，就可以让他们的结合更松散了，这里就不多说了。

接下来我们还有一个问题，Prize绩效的制度，上一篇的设计，每一个员工的工资都会创建一个Prize，而Prize只是固定的制度，员工都是遵守和共享这个制度的，这样就造成了内存的浪费，怎么去解决这个问题呢，让系统中只存在我们想要的固定数目的Prize的实例呢？

Singleton(单件)：保证一个类仅有一个实例，并提供一个访问它的全局访问点。和我们的意图一样，那就用它吧。



public interface IPrize

{

double GetPrize(Salary salary);

}

public class BadPrize : IPrize //绩效不好的奖金比率

{

public static readonly BadPrize badPrize = new BadPrize(); //在这里使用静态只读,做到badPrize不可被修改

private BadPrize()//在这里使用私有构造,做到BadPrize类不可被实例化

{ }

public double GetPrize(Salary salary)

{

return salary.SalaryNum * 0.5; //干的不好奖金扣一半

}

}

public class GoodPrize : IPrize //绩效好的奖金比率

{

public static readonly GoodPrize goodPrize = new GoodPrize();

private GoodPrize()

{ }

public double GetPrize(Salary salary)

{

return salary.SalaryNum * 1; //干的好奖金全发，哈哈

}

}

这样我们就保证了，在系统运行时BadPrize和GoodPrize都只有一个实例，完成了我们的设计。

现在来看看调用程序：



class Program

{

static void Main(string[] args)

{

Staff staff = new Staff();

staff.PersonName="涵舍愚人";

Console.Write(staff.PersonName + "本月实发工资为" + staff.GetShouldpaid(BadPrize.badPrize)); //由原先的new BadPrize(),变为现在的单件badPrize

Console.Read();

}

}

输出结果：



由于这个月干的不好，绩效工资被扣一半．．．．．:(

我们使用了两种设计模式Factory Method和Singleton ,来封装了员工的工资创建和绩效工资的单件,好了这样我们就设计完成了用户的需求,下一篇中可恶的客户要添加需求了。。(在实际开发中这种事情的发生频率，地球上的程序员都知道啦。)