您的位置:首页 > 其它

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

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

一直很想写关于设计模式的具体使用的文章,可是一直没想好怎么去写,才可以通俗易懂,真正的让设计模式,应用到系统设计中.今天终于想到了,这个系列准备用实例去讲解如何使用(GOF)设计模式.

准备用公司的人员管理系统来做这个实例,为什么选他呢?我觉得大家基本上都是公司员工,对这方面会比较熟悉.OK我们现在来定义这个系统.

客户A说:我们的系统要管理人员的工资.(为了模拟真实的开发场景,这里暂时先定义一个功能)人员分为实习员工和正式员工,他们的基本工资是不同的,工资包括基本工资和绩效工资.

1.分析

好,那我们现在就来分析这个系统吧,如何分析呢.大家都知道在面向对象分析中,比较难的是如何划分和定义一个类, 这里给大家介绍一个方法,"名词分析法",也就是用名词来划分你的类.举个例子:上面客户A说:"我们的系统要管理人员的工资",当然这里"我们"和"系统"这两个名词没有什么意义,就不去管它们了,我们来看接下来的"人员的工资",这里出现了人员和工资,那么我们就把他们定义成两个类Person和Salary.下面的需求:"人员分为实习员工和正式员工",那么就有实习员工和正式员工两个类,还有基本工资和绩效工资.

2.过滤

好,我们通过分析得到了 Person,InternshipSalary(实习员工),SttafSalary(正式员工),后两者也属于员工,那么我们只需要定义person,然后衍生出实习员工和正式员工,就可以了.

Salary,基本工资,绩效工资:由于绩效工资和公司的制度关系很密切,变化可能会很频繁,而使用设计模式的目的就是封装变化,使得代码更好的复用,所以我们要把绩效工资和Salary分开,单独封装,而基本工资就是一个数,所以直接作为Salary的一个属性就可以了.

3.设计

我们来看客户的话:"人员分为实习员工和正式员工,他们的基本工资是不同的,工资包括基本工资和绩效工资."

在这里Person应该包含Salary这个类,但是Person和Salary都有2种分类,而且客户很有可能再添加新的分类,那么我们如何来避免这种需求改变而带来的修改呢??

GOF23中的Bridge(桥接),就可以完成这个设计.我们来看下Bridge这种设计模式的意图:将抽象部分与他的实现部分分离,使他们都可以独立的变化.和我们的意图相符合.

我们知道工资中包含绩效工资,而绩效工资实际上就是一个算法,(在这里我们先不讨论怎么去评判一个人的绩效),完成多少的人给多少的绩效工资.每个人每月的绩效都不一样,可能根据很多情况发生变化.怎么来设计呢?

GOF23中的Strategy(策略):定义一系列算法,使他们可以互相替换.独立于客户代码而变换.就是他了,嘿嘿!!

4.类图



嘿嘿,可能大家已经看出来Bridge模式和Stratege模式很像了吧,其实他们的类图确实是一样的,从不太严格的角度来说:可以认为他们是一种实现方式,但是他们的意图不一样,Bridge更多的是类与类之间的关系,而Stratege是类与行为之间的关系,也就是说Bridge是对某一个类的一系列可变的封装,而Stratege则是对某一种可变的算法的封装。

2.代码:

绩效奖金的实现:



public interface IPrize

{

double GetPrize(Salary salary);

}

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

{

public double GetPrize(Salary salary)

{

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

}

}

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

{

public double GetPrize(Salary salary)

{

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

}

}

工资的实现:



public abstract class Salary

{

protected double _salaryNum; //工资基数

protected IPrize _salaryprize; //这里维护一个绩效奖金的引用。

public double SalaryNum

{

get { return _salaryNum; }

set { _salaryNum = value; }

}

public IPrize Salaryprize

{

get { return _salaryprize; }

set { _salaryprize = value; }

}

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

}

public class InternshipSalary : Salary //实习者的应得工资

{

public override double GetShouldpaid()

{

_salaryNum = 3000;//实习者的工资基数

return _salaryNum + _salaryprize.GetPrize(this);

}

}

public class SttafSalary : Salary //员工的应得工资

{

public override double GetShouldpaid()

{

_salaryNum = 6000;//正式员工的工资基数

return _salaryNum + _salaryprize.GetPrize(this);

}

}

员工的实现:



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();

}

}

public class Internship : AbstractPerson

{

public override double GetShouldpaid(IPrize prize)

{

_personSalary = new InternshipSalary();//初始化实习员工的基本工资

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

return _personSalary.GetShouldpaid();

}

}

调用程序:



class Program

{

static void Main(string[] args)

{

Staff staff = new Staff();

staff.PersonName="涵舍愚人";

Console.Write(staff.PersonName+"本月实发工资为"+staff.GetShouldpaid(new GoodPrize()));

Console.Read();

}

}

输出结果:



我们使用了两种设计模式Bridge和Strategy ,来封装了员工和工资,以及工资和绩效的变化,好了这样我们就设计完成了用户的需求,但是就上面的设计,还是有很多漏洞的,下一篇我们将继续用模式优化这些设计.
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: