在前三篇中我们设计了员工的工资,绩效将金,以及员工福利,使用了Bridge(员工和工资的组合),Stratege(工资和绩效将金的设计)以及(Singleton)单件了这些算法,然后用Decorator(装饰)将员工进行职位的装饰.这些设计在我们前面所说的场景下,是符合设计模式的意图的,但是它仍然有一些漏洞.

我们来看看我们的员工类的代码,注意注释的文字.

 

 

Code

 

 上面的设计使得Person和Iprize耦合,而且Person与Salary的结合也不是很灵活,怎么去解决这个问题呢.

 

先来解决Person和Salary: Person和Salary使用了Bridge模式,该模式的做到了两个类系列的独立变化.那么我们就要有种方式去生成这两个系列.

AbstractFactory(抽象工厂):提供一个创建一系列相关或相互依赖对象的接口,而无需指定它们具体的类。

ok,这个模式适合我们的设计意图.第二篇里面我们用了工厂方法来创建工资,同样我们也可以用它来创建Person.这样Person发生了变化,并不会影响到我们的抽象工厂.(回忆一下第二篇中工厂方法的意图)下面我们来看看代码:

 

 

工资的工厂方法:

 

Code

 

 

员工的工厂方法:

 

Code

 

生成员工和工资的抽象工厂:

 

 

Code

 

 

好了,解决了Person和Salary的创建问题,我们来看看Person和Iprize的依赖问题. Iprize属于工资的一部分,那么他的创建和依赖应该在Salary这个类,而且我们已经单件了Iprize的子类.并且上面我们解决了Person里创建Salary的问题,所以我们将Person类,修改成如下:

 

 

Person类:

 

 

Code

 

 

 

 还有我们原有的Duty类的代码(他是不需要修改的):

 

Code

 

 

调用程序:

 

 

 

Code

 

 

 输出结果:

 

 

这样我们就用抽象工厂把Person与Salary的紧耦合给解耦了,如果工资的需求变更了Staff中的Salary可以是任何的Salary子类,并不会影响到Person.

这里要说明一下,工厂方法和抽象工厂通常用单件形式,因为这两个工厂模式的职责是创建对象,所以工厂有一个就足够了,因第二篇使用了单件,这里不在赘述,只要记得工厂通常是单件就好.

 

(关于工厂方法和抽象工厂的区别:工厂方法创建一个产品,而抽象工厂创建一系列的产品)

 

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

posted on 2008-08-14 08:40  徐 磊  阅读(3756)  评论(10编辑  收藏  举报