首页 诗词 字典 板报 句子 名言 友答 励志 学校 网站地图
当前位置: 首页 > 教程频道 > 软件管理 > 软件开发 >

设计模式之责任链方式(转)

2013-11-29 
设计模式之责任链模式(转)一. 写在前面的这么多的设计模式,我觉得职责链是我第一次看上去最简单,可是回想

设计模式之责任链模式(转)

一. 写在前面的

这么多的设计模式,我觉得职责链是我第一次看上去最简单,可是回想起来却又最复杂的一个模式。

因此,这个文章我酝酿了很久,一直也没有胆量发出来,例子也是改了又改,可是仍然觉得不够合理。所以希望各位多多指教。

二. 什么是链

设计模式之责任链方式(转)

文章伊始,先让我们了解这个最基本的概念,什么是链。

我给链下了这样的定义:

1. 链是一系列节点的集合。

2. 链的各节点可灵活拆分再重组。

三. 何为职责链

职责链模式:使多个对象都有机会处理请求,从而避免请求的发送者和接受者之间的耦合关系。将这个对象连成一条链,并沿着这条链传递该请求,直到有一个对象处理他为止。

图如下:

设计模式之责任链方式(转)

UML很简单,让我们先来看一个简单的例子。

四. 职责链模式应用之请假管理

请假这个事情,相信每个人都不陌生。

我们公司是个相对很宽松的公司。

在公司里,如果你的请假时间小于0.5天,那么只需要向项目经理打声招呼就OK了。

如果超过了0.5天,但是还小于2天,那么就要去找人事部处理,当然,这就要扣工资了。

如果超过了2天,你就需要去找总经理了,工资当然也玩完了。

那么,对于我们来说,这个流程就是这样的。

设计模式之责任链方式(转)

也就是这样一个过程,你需要和你的直接上级——项目经理去打交道,最终可能是项目经理给你回邮件,

可能是人事部给你回邮件,也可能是总经理给你回邮件。内部的过程其实应该是个黑盒子,

你并不知道内部的消息是如何处理的。你需要找到的,只是你想要第一个交付的对象而已。

设计模式之责任链方式(转)

那么我们的代码应该是这样的。

首先我们要写一个请求的类。

class?Request?{
?private int?day;
?private string?reason;?
public int?Day {?get?{?return?day; }?set?{ day =?value; } }?public string?Reason {?get?{?return?reason; }?set?{ reason =?value; } }?publicRequest(int?day,?string?reason) {?this.day = day;?this.reason = reason; } }
接下来看下请求相应者,他们有两个核心方法,一个是相应操作,一个是选择继任者。
abstract class?Boss?{?private string?name;?public string?Name {?get?{?return?name; }?set?{ name =value; } }?private?Boss?successor;?public?Boss?Successor {?get?{?return?successor; }?set?{ successor =value; } }?public?Boss(string?name) {?this.name = name; }?public abstract bool?PassRequest(Requestrequest); }?class?PM:Boss?{?public?PM(string?name) :?base(name) { }?public override boolPassRequest(Request?request) {?int?day = request.Day;?string?reason = request.Reason;?if?(day <= 0.5) {?return true; }?return?Successor.PassRequest(request); } }?class?HR:Boss?{?public?HR(string?name) :base(name) { }?public override bool?PassRequest(Request?request) {?int?day = request.Day;?stringreason = request.Reason;?if?(day > 0.5&&day<=2) {?return true; }?returnSuccessor.PassRequest(request); } }?class?Manager?:?Boss?{?public?Manager(string?name) :?base(name) { }?public override bool?PassRequest(Request?request) {?int?day = request.Day;?string?reason = request.Reason;?if?(reason.Equals("正当理由")) {?return true; }?return false; } }

那么我们调用的时候就很简单了!

static void?Main(string[] args) {?Request?request =?new?Request(3,?"非正当理由");?Boss?pm =?newPM("pm");?Boss?hr =?new?HR("hr");?Boss?manager =?new?Manager("manager"); pm.Successor = hr; hr.Successor = manager;?bool?pass = pm.PassRequest(request);?Console.Write(pass); }

五. 灵活在哪?

让我们来看下职责链究竟灵活在哪?

1. 改变内部的传递规则。

设计模式之责任链方式(转)

在内部,项目经理完全可以跳过人事部到那一关直接找到总经理。

每个人都可以去动态地指定他的继任者。

2. 可以从职责链任何一关开始。

如果项目经理不在,那么完全可以写这样的代码:

static void?Main(string[] args) {?Request?request =?new?Request(3,?"非正当理由");?Boss?pm =?newPM("pm");?Boss?hr =?new?HR("hr");?Boss?manager =?new?Manager("manager"); pm.Successor = hr; hr.Successor = manager;?//bool pass = pm.PassRequest(request);?bool?pass = hr.PassRequest(request);Console.Write(pass); }

?

3. 我们来比较一下,用职责链和不用职责链的区别:

设计模式之责任链方式(转)

这是不用职责链我们的结构,我们需要和公司中的每一个层级都发生耦合关系。

如果反映在代码上即使我们需要在一个类中去写上很多丑陋的if….else语句。

如果用了职责链,相当于我们面对的是一个黑箱,我们只需要认识其中的一个部门,然后让黑箱内部去负责传递就好了。

六. 职责链 != 链表

很多人都愿意把职责链和链表混为一谈,确实,从字面意思上理解,链,链表,很像。可是他们一样么?

他们区别在哪里:

让我们看一个链表的典型结构:

设计模式之责任链方式(转)

让我们来看一下链表的典型特征:

1. 链表是一个链状结构,每个节点有一个next属性去指向他的下一节点。

2. 链表有一个Header节点,然后用户每次必须通过头节点,然后去遍历寻找每一个节点。

3. 链表遍历操作的复杂度是O(n),但是插入和删除指定节点的复杂度是常数级。

让我们来着重看这第二点:

我们来想想在文章开始时我们画出的那个链,一个链,我们可以从头将他拿起,也可以从中间将他拿起:

设计模式之责任链方式(转)

也就是说我们用户可以去访问节点中的任何一个节点作为开始节点,这就是链表与职责链不同的地方。

七. 职责链的扩展——树状链结构

职责链中,我们之前看到的都是一些单链结构,但是其实在很多情况下,每一个节点都对应着很多其他的部分。

设计模式之责任链方式(转)?

那么这样,我们的每一个节点都可以使用一个List来维护他节点的下一节点,甚至可以用组合模式来分别设计每一节点。

八. 由法律想到——职责链的兜底条款

仔细想想法律条文,尤其是刑法,经常可以看到这样的条文:

1. 如果*********,则处以拘役处分。

2. 如果*********,则处以有期徒刑一年到十年。

3. 如果*********,则处以有期徒刑十年以上。

4. 如果*********,则**********。

5. 如果以上条件皆不满足,则*****************。

其实最后一条就叫做法律的兜底条款。这给了法官很大的自由裁量权,在一定程度上也降低了犯罪分子钻法律空子的可能性。

在我们的职责链中,如果不存在这样的兜底条款,那么用户如果不从首节点开始访问,那么就很可能出现异常的情况。于是我们应该为职责链设置一个默认的条款:

设计模式之责任链方式(转)

这样的话,任何一个处理无论如何访问,都能得到一个正常的处理。

九. 职责链的缺点

让我们继续回到上面的例子,我们发现,其实当请假时间超过2天的时候,PM和HR其实没有做任何的事情,而只是做了一个传递工作。

而传递工作之后,他们就成了垃圾对象。

也就是说,他们在实际的处理中,并没有发挥任何的作用。

那么当这个链结构比较长,比较复杂的话,会产生很多的内存垃圾对象。

这也就是职责链的最大缺点之所在。

十. 职责链的乱用

在和其他的人的讨论中,我发现他们的观点是:

只要一者传一者,那么就要用职责链。在我们的项目中,他们这样去用:

abstract class?DBHelper?{ }?interface?IRequestHandler?{ IDBHelper ReturnHelper(string?dbName); }?classRequestHandler:IRequestHandler?{?private?RequestHandler?successor;?public?RequestHandler?Successor {get?{?return?successor; }?set?{ successor =?value; } }?public abstract?IDBHelper ReturnHelper(stringdbName); }?class?SQLHelper?:?DBHelper?{ }?class?OracleHelper?:?DBHelper?{ }?class?DB2Helper?:?DBHelper{ }?class?SQL?:?RequestHandler?{?public override?IDBHelper ReturnHelper(string?dbName) {?if(dbName.Equals("SQL Server")) {?return new?SQLHelper(); }?return?Successor.ReturnHelper(dbName); } }class?Oracle?:?RequestHandler?{?public override?IDBHelper ReturnHelper(string?dbName) {?if(dbName.Equals("Oracle")) {?return new?OracleHelper(); }?return?Successor.ReturnHelper(dbName); } }class?DB2?:?RequestHandler?{?public override?IDBHelper ReturnHelper(string?dbName) {?if(dbName.Equals("DB2")) {?return new?DB2Helper(); }?return new?SQLHelper(); } }

?

这样的话,每个类相当于只负责一个操作。

那么我们如何改进呢?第一,我们可以用一个工厂来实现。另外,我们可以用表驱动的方式来解决问题。

十一. 表驱动改进职责链

表驱动(Table driven),其实就是指用查表的方式来获取值。

那么我们用标驱动法来改进上面的例子:

class?HelperRequest?{?private?Dictionary<String,?DBHelper> dic =?new?Dictionary<string,?DBHelper>();public void?Add(string?name,DBHelper?helper) { dic.Add(name, helper); }?public?DBHelperGetHelper(string?name) {?DBHelper?helper;?bool?temp = dic.TryGetValue(name,?out?helper);?if?(temp) {return?helper; }?return null; } }

我想一个没有学过设计模式的人都会这样写的。一个学过设计模式很多年的人也会这样写的。

而怕的就是为了模式而模式,为了职责链而职责链了。

十二. 职责链在java script中的应用

我们想象这样一种情况:

设计模式之责任链方式(转)

我们都知道,在ASP.NET 的 Webform模型中页面是以控件树的形式去组织的。那么我们用右键点击其中的一个页面,那么这个事件就会找离他最近的控件,如果不存在,那么就去找他的父控件,如此递归下去,直到找到为止。

这其实就是一种职责链的体现!

十三. 深析职责链的使用

职责链模式不能乱用,否则非常容易变成因为模式而模式的反例。

下面是我归纳出来的一些关于职责链方面的使用规则,只是个人的意见,还希望大家指教。

1, 如果存在N对N,或者是一般的常规线性关系,那么我们完全可以用表驱动来取代职责链。

2, 对象本身要经过什么处理是通过每个链上元素通过运行态来决定的,决定的因素是取决于对象的属性或者一些其他方面的策略。

3, 用户无论是从哪一个节点作为他的请求头节点,最终用户都可以得到一个请求的反馈。

4,?应怪怪建议,补充同级的处理!职责链并非是严格的上下级的传递,其中也包括同级的传递,职责链一样可以在同级之间做传递。

例如,继续用我们上面请假的那个做例子,也许我们公司有两个HR,事实上也是这样的,我们把前台“MM”也美称为人力资源部:

static void?Main(string[] args) {?Request?request =?new?Request(3,?"非正当理由");?Boss?pm =?newPM("pm");?Boss?hr1 =?new?HR("Real HR");?Boss?hr2 =?new?HR("QiantaiMM");?Boss?manager =?newManager("manager"); pm.Successor = hr1; hr1.Successor = hr2; hr2.Successor = manager;?bool?pass = pm.PassRequest(request);?Console.Write(pass); }

其实这样也未尝不可。有人也许会说,那么这样的同样一个类的两个对象又有什么意义呢?

那么我们不妨去试着这样改造这个HR的类。

enum?HRType?{ RealHR, Qiantai }?class?HR:Boss?{?private?HRType?type;?public?HR(string?name,HRTypetype) :?base(name) {?this.type = type; }?public override bool?PassRequest(Request?request) {?int?day = request.Day;?if?(day>=0.5&&day<2) {?switch?(type) {?case?HRType.RealHR:?//扣工资?return true;?break;case?HRType.Qiantai:?//不扣工资?return true;?break; } }?return?Successor.PassRequest(request); } }

这样,因为前台MM容易说话,很可能他就不去扣你的工资,如果你去先找的HR,那么你这天的工资就报销了。

同理,我们一样可以让他们的职责细化,比如说Real Hr负责0.5天到1天的,而Qiantai去负责1天到2天的,也未尝不可。

总之,职责链并非是单一的上下级的传递,一样可以实现同级的传递。

?

十四. 职责链总结

职责链是使多个对象都有机会处理请求,从而避免请求的发送者和接受者之间的耦合关系。将这个对象连成一条链,并沿着这条链传递该请求,直到有一个对象处理他为止。

今天就写到这了,希望大家多多指教。

热点排行