随笔 - 28  文章 - 4 评论 - 567 trackbacks - 54

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

 

 

前面我们设计了员工的工资,奖金,福利系统。今天客户又来增加需求了:"我们需要统计公司,部门,或者小组的薪资成本。"得到了需求,我们还是按照老套路来完成我们的设计。

 

 

1.分析

我们用"名词分析法"来分析需求里面的类(第一篇有讲解),薪资的部分我们已经有了,需求中包含公司,部门,小组这三个名词。好的我们来过滤它。 

 

2.过滤

好,我们通过分析得到了公司,部门,小组。这里要考虑以后可能有的变化,最常见的是公司去添加一个层级,比如添加一个分公司。我们不能把公司,部门,小组,分别当成一个类来处理,这样添加层级的时候,我们又要重新写代码,然后编译发布,这是我们要极力避免的。那么怎么去做呢?其实说白了,公司的组织结构都是由Person组成的,一个树形结构。我们可以把它们统一起来,让客户程序在使用公司,部门,小组,或者人的时候具有统一性。那么我们就设计一个类就足够了。

 

3.设计

我们来看客户的话:"我们需要统计公司,部门,或者小组的薪资成本",也就是说我们的这个类可能要维护一个人员的列表,然后把它们的工资,福利加起来最后生成一个组织的薪资成本.需要考虑的是很有可能一个人不属于任何部门,也就是说他和公司平级,或者不属于任何小组,他和部门平级,所以这里我们对待组织和对待人必须要一样,否则我们只能去遍历判断这个节点下到底是个组织还是员工。总结一下我们的设计意图:我们希望形成一个树层次结构,而且要让组织的操作和人员的操作一样。怎么做??

 

GOF23中的Composite(组合):将对象组合成树形结构以表示“部分-整体”的层次结构。使得用户对单个对象和组合对象的使用具有一致性。 与我们的意图相符,OK,就是它,我们开始具体设计吧!

 

4.类图(为了回顾前面的设计,这次贴出设计全部类图,本篇的设计看红色框起来的部分)

 

 

 

 

我们设计了一个接口Icomposite,并且让Person,PersonComposite继承自它

 

代码:

Icomposite,Composite:

 

Code

 

Person:

 

Code

 

客户代码:

 

 

Code

 

 

输出结果:

 

 

Composite模式和前面使用的Decorator模式大体上是一样的,对他们的父类都有一个Has-a(拥有)的关系,同时又是Is-a,所以Decorator可以无限添加功能,而Composite也可以无限添加节点,只因它们是同根生...唯一的区别就是:Composite是维护父类列表,Decorator维护了一个父类(其实就是他自己).

 

OK,这样我们完成就了用户的需求,但是还有一些不足,下一篇我们来完善它.

 

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

 

 

posted on 2008-08-15 14:47  徐 磊  阅读(...)  评论(...编辑  收藏