职责链模式分析、结构图与基本代码

??

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

优点:当客户提交一个请求时,请求时沿链传递直至有一个ConcreteHandler对象负责处理它。这就使得接收者和发送者都没有对方的明白信息,且链中的对象自己也并不知道链的结构。

结果是职责链可简化对象的相互连接,它们仅需保持一个指向其后继者的引用,而不需保持它全部的候选接收者的引用。这就大大减少了耦合度了。因为式在client来定义链的结构,也就是说。我能够随时得添加或改动处理一个请求的结构。

增强了给对象指派职责的灵活性。

结构图:

基本代码:

using System;

using System.Collections.Generic;

using System.Text;

namespace 职责链模式

{

class Program

{

static void Main(string[] args)

{

Handler h1 = new ConcreteHandler1();

Handler h2 = new ConcreteHandler2();

Handler h3 = new ConcreteHandler3();

h1.SetSuccessor(h2);

h2.SetSuccessor(h3);

int[] requests = { 2, 5, 14, 22, 18, 3, 27, 20 };

foreach (int request in requests)

{

h1.HandleRequest(request);

}

Console.Read();

}

}

abstract class Handler

{

protected Handler successor;

public void SetSuccessor(Handler successor)

{

this.successor = successor;

}

public abstract void HandleRequest(int request);

}

class ConcreteHandler1 : Handler

{

public override void HandleRequest(int request)

{

if (request >= 0 && request < 10)

{

Console.WriteLine("{0}  处理请求  {1}",

this.GetType().Name, request);

}

else if (successor != null)

{

successor.HandleRequest(request);

}

}

}

class ConcreteHandler2 : Handler

{

public override void HandleRequest(int request)

{

if (request >= 10 && request < 20)

{

Console.WriteLine("{0}  处理请求  {1}",

this.GetType().Name, request);

}

else if (successor != null)

{

successor.HandleRequest(request);

}

}

}

class ConcreteHandler3 : Handler

{

public override void HandleRequest(int request)

{

if (request >= 20 && request < 30)

{

Console.WriteLine("{0}  处理请求  {1}",

this.GetType().Name, request);

}

else if (successor != null)

{

successor.HandleRequest(request);

}

}

}

}

样例:

using System;

using System.Collections.Generic;

using System.Text;

namespace 职责链模式

{

class Program

{

static void Main(string[] args)

{

CommonManager jinli = new CommonManager("金利");

Majordomo zongjian = new Majordomo("宗剑");

GeneralManager zhongjingli = new GeneralManager("钟精励");

jinli.SetSuperior(zongjian);

zongjian.SetSuperior(zhongjingli);

Request request = new Request();

request.RequestType = "请假";

request.RequestContent = "小菜请假";

request.Number = 1;

jinli.RequestApplications(request);

Request request2 = new Request();

request2.RequestType = "请假";

request2.RequestContent = "小菜请假";

request2.Number = 4;

jinli.RequestApplications(request2);

Request request3 = new Request();

request3.RequestType = "加薪";

request3.RequestContent = "小菜请求加薪";

request3.Number = 500;

jinli.RequestApplications(request3);

Request request4 = new Request();

request4.RequestType = "加薪";

request4.RequestContent = "小菜请求加薪";

request4.Number = 1000;

jinli.RequestApplications(request4);

Console.Read();

}

}

//管理者

abstract class Manager

{

protected string name;

//管理者的上级

protected Manager superior;

public Manager(string name)

{

this.name = name;

}

//设置管理者的上级

public void SetSuperior(Manager superior)

{

this.superior = superior;

}

//申请请求

abstract public void RequestApplications(Request request);

}

//经理

class CommonManager : Manager

{

public CommonManager(string name)

: base(name)

{ }

public override void RequestApplications(Request request)

{

if (request.RequestType == "请假" && request.Number <= 2)

{

Console.WriteLine("{0}:{1} 数量{2} 被批准", name, request.RequestContent, request.Number);

}

else

{

if (superior != null)

superior.RequestApplications(request);

}

}

}

//总监

class Majordomo : Manager

{

public Majordomo(string name)

: base(name)

{ }

public override void RequestApplications(Request request)

{

if (request.RequestType == "请假" && request.Number <= 5)

{

Console.WriteLine("{0}:{1} 数量{2} 被批准", name, request.RequestContent, request.Number);

}

else

{

if (superior != null)

superior.RequestApplications(request);

}

}

}

//总经理

class GeneralManager : Manager

{

public GeneralManager(string name)

: base(name)

{ }

public override void RequestApplications(Request request)

{

if (request.RequestType == "请假")

{

Console.WriteLine("{0}:{1} 数量{2} 被批准", name, request.RequestContent, request.Number);

}

else if (request.RequestType == "加薪" && request.Number <= 500)

{

Console.WriteLine("{0}:{1} 数量{2} 被批准", name, request.RequestContent, request.Number);

}

else if (request.RequestType == "加薪" && request.Number > 500)

{

Console.WriteLine("{0}:{1} 数量{2} 再说吧", name, request.RequestContent, request.Number);

}

}

}

//申请

class Request

{

//申请类别

private string requestType;

public string RequestType

{

get { return requestType; }

set { requestType = value; }

}

//申请内容

private string requestContent;

public string RequestContent

{

get { return requestContent; }

set { requestContent = value; }

}

//数量

private int number;

public int Number

{

get { return number; }

set { number = value; }

}

}

}

时间: 2024-08-02 07:53:34

职责链模式分析、结构图与基本代码的相关文章

设计模式的征途—14.职责链(Chain of Responsibility)模式

相信大家都玩过类似于“斗地主”的纸牌游戏,某人出牌给他的下家,下家看看手中的牌,如果要不起,则将出牌请求转发给他的下家,其下家再进行判断.一个循环下来,如果其他人都要不起该牌,则最初的出牌者可以打出新牌.在这个过程中,纸牌作为一个请求沿着一条链在传递,每一位纸牌的玩家都可以处理该请求.在设计模式中,也有一种专门用于处理这种请求链式的模式,它就是职责链模式. 职责链模式(Chain of Responsibility) 学习难度:★★★☆☆ 使用频率:★★☆☆☆ 一.采购单的分级审批模块设计 需求

设计模式之职责链模式(Chain of Responsibility)摘录

23种GOF设计模式一般分为三大类:创建型模式.结构型模式.行为模式. 创建型模式抽象了实例化过程,它们帮助一个系统独立于怎样创建.组合和表示它的那些对象.一个类创建型模式使用继承改变被实例化的类,而一个对象创建型模式将实例化托付给还有一个对象.创建型模式有两个不断出现的主旋律.第一,它们都将关于该系统使用哪些详细的类的信息封装起来.第二,它们隐藏了这些类的实例是怎样被创建和放在一起的.整个系统关于这些对象所知道的是由抽象类所定义的接口.因此,创建型模式在什么被创建,谁创建它,它是怎样被创建的,

java设计模式之职责链模式

[学习难度:★★★☆☆,使用频率:★★☆☆☆] "一对二","过","过"--这声音熟悉吗?你会想到什么?对!纸牌.在类似"斗地主"这样的纸牌游戏中,某人出牌给他的下家,下家看看手中的牌,如果要不起上家的牌则将出牌请求再转发给他的下家,其下家再进行判断.一个循环下来,如果其他人都要不起该牌,则最初的出牌者可以打出新的牌.在这个过程中,牌作为一个请求沿着一条链在传递,每一位纸牌的玩家都可以处理该请求.在设计模式中,我们也有一种专

Android开发-分析ViewGroup、View的事件分发机制、结合职责链模式

介绍 上一篇博客职责链/责任链模式(Chain of Responsibility)分析理解和在Android的应用 介绍了职责链模式,作为理解View事件分发机制的基础. 套用职责链模式的结构分析,当我们的手指在屏幕上点击或者滑动,就是一个事件,每个显示在屏幕上的View或者ViewGroup就是职责对象,它们通过Android中视图层级组织关系,层层传递事件,直到有职责对象处理消耗事件,或者没有职责对象处理导致事件消失. 关键概念介绍 要理解有关View的事件分发,先要看几个关键概念 Mot

设计模式之职责链

职责链(Chain of Responsibility)模式属于23种设计模式之一,职责链也称为责任链,<Design pattern: the basis of reusable object-oriented software>(以下简称DP)一书中是这样描述职责链的:职责链模式使多个对象都有机会处理请求,从而避免请求发送者和接收者之间的耦合关系.将这个对象连成一条链,并沿这条链传递该请求,直到有一个对象处理它为止. DP中对职责链模式的定义稍微不是那么的好理解,简单来说就是将能够处理用户

模板方法模式分析、结构图和基本代码

 定义:模板方法模式定义一个操作中的算法的骨架,而将一些步骤延迟到子类中.模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤. 结构图: AbstractClass是抽象类,其实也就是一抽象模板,定义并实现了一个模板方法.这个模板方法一般是一个具体方法,它给出了一个顶级逻辑的骨架,而逻辑的组成步骤在相应的抽象操作中,推迟到子类实现.顶级逻辑也有可能调用一些具体方法. ConcreteClass,实现父类所定义的一个或多个抽象方法.每一个AbstractClass都可以有任

观察者模式分析、结构图及基本代码

 定义:观测者模式定义了一种一对多的依赖关系,让多个观测者对象同时监听某一个主题对象.这个主题对象在状态发生变化时,会通知所有观测者对象,使它们能够自动更新自己. 结构图: Subject类,可翻译为主题或抽象通知者,一般用一个抽象类或者一个接口实现.它把所有对观察者对象的引用保存在一个聚集里,每个主题都可以有任何数量的观察者.抽象主题提供一个接口,可以增加和删除观测者. Observe类,抽象观测者,为所有的具体观察者定义一个接口,在得到主题的通知时更新自己.这个接口叫更新接口.抽象观察者

迭代器模式分析、结构图及基本代码

定义:提供一种方法顺序访问一个聚合对象中的各个元素,而又不暴露该对象的内部表示. 适用地方:当需要访问一个聚集对象,而且不管这些对象是什么都需要遍历的时候,就应该考虑用迭代器模式.或者当需要对聚集有多种方式遍历时,可以考虑使用迭代器模式. 尽管我们不需要显式地引用迭代器,但系统本身还是通过迭代器来实现遍历的.总的来说,迭代器模式就是分离了集合对象的遍历行为,抽象出一个迭代器类来负责,这样既可以做到不暴露集合的内部结构,又可让外部代码透明的访问集合内部的数据.迭代器模式在访问数组.集合.列表等数据

备忘录模式分析、结构图及基本代码

 定义 在不破坏封装性的前提下,捕获一个对象的内部状态,并在该对象之外保存这个状态.这样以后就可将该对象恢复到原先保存的状态. 结构图: Originator(发起人):负责创建一个备忘录Memento,用以记录当前时刻它的内部状态,并可使用备忘录恢复内部状态.Originator可根据需要决定Memento存储Originator的哪些内部状态. Memento(备忘录):负责存储Originator对象的内部状态,并可防止Originator以外的其他对象访问备忘录Memento.备忘录