2. 程式人生 > >設計模式（十八）——職責鏈模式

設計模式（十八）——職責鏈模式

阿新 • • 發佈：2017-10-04
設計模式 職責鏈模式

設計模式（十八）——職責鏈模式

一、職責鏈模式簡介

1、職責鏈模式簡介

職責鏈模式（Chain Of Responsibility）使多個對象都有機會處理請求，從而避免請求的發送者和接收者之間的耦合。將可能處理請求的對象連成一條鏈，並沿著這條鏈傳遞請求，直到有一個對象處理請求為止。

技術分享

2、職責連模式角色

Handle

r類：職責對象抽象類，定義一個處理請求的接口。

ConcreteHandler類：職責對象具體類，實現具體的處理請求的接口。

3、職責鏈模式優缺點

職責鏈模式的優點：

A、當客戶提交一個請求時，請求是沿鏈傳遞直至有一個ConcreteHandler對象負責處理請求。

B、接收者和發送者都沒有對方的明確信息，且鏈中的對象自己也並不知道鏈的結構。結果是職責鏈可簡化對象的相互連接，僅需要保持一個指向其後繼者的引用，而不需要保持所有的候選接收者的引用。

C、由於是在客戶端來定義鏈的結構，所以用戶可以隨時地增加或者修改處理一個請求的結構，增強了給對象指派職責的靈活性。


職責鏈模式的缺點：

一個請求極有可能到了鏈的末端都得不到處理，或者因為沒有正確配置而得不到處理。

4、職責鏈模式使用場景

職責鏈模式使用場景：

A、有多個的對象可以處理一個請求，哪個對象處理該請求運行時刻自動確定。

B、在不明確指定接收者的情況下，向多個對象中的一個提交請求。

C、可處理一個請求的對象集合應被動態指定。

二、職責連模式實現

Handler抽象類：

#ifndef HANDLER_H
#define HANDLER_H
#include <iostream>
using namespace std;
 
//處理請求的抽象類
class Handler
{
public:
    //設置後繼處理請求者
    void setSuccessor(Handler* successor)
    {
        m_successor = successor;
    }
    //處理請求的接口
    virtual void handleRequest(int n) = 0;
protected:
    Handler(){}
protected:
    Handler* m_successor;//後繼者
};
 
#endif // HANDLER_H


ConcreteHandlerA具體處理類：

#ifndef CONCRETEHANDLERA_H
#define CONCRETEHANDLERA_H
#include "Handler.h"
 
//處理請求的具體實現類
class ConcreteHandlerA : public Handler
{
public:
    void handleRequest(int n)
    {
        if(n < 1000)
        {
            cout << "ConcreteHandlerA::handleRequest n = " << n << endl;
        }
        else//如果n>1000，由後繼者處理請求
        {
            if(m_successor)
                m_successor->handleRequest(n);
        }
    }
};
 
#endif // CONCRETEHANDLERA_H


ConcreteHandlerB具體處理類：

#ifndef CONCRETEHANDLERB_H
#define CONCRETEHANDLERB_H
#include "Handler.h"
 
//處理請求的具體實現類
class ConcreteHandlerB : public Handler
{
public:
    void handleRequest(int n)
    {
        cout << "ConcreteHandlerB::handleRequest n = " << n << endl;
    }
};
 
#endif // CONCRETEHANDLERB_H


客戶調用程序：

#include "Handler.h"
#include "ConcreteHandlerA.h"
#include "ConcreteHandlerB.h"
 
int main()
{
    Handler* a = new ConcreteHandlerA();
    Handler* b = new ConcreteHandlerB();
 
    a->setSuccessor(b);
    a->handleRequest(200);
    a->handleRequest(1200);
 
    delete a,b;
 
    return 0;
}


三、職責鏈模式實例

公司中對於請假、加薪等請求有不同的處理流程，不同的請求需要由經理、技術總監、總經理處理。但所有的請求必須提交給經理，如果經理沒有權限，轉給技術總監，技術總監沒有權限，轉給總經理處理。

技術分享

Request請求類：

#ifndef REQUEST_H
#define REQUEST_H
#include <string>
using namespace std;
 
//請求
class Request
{
public:
    void setType(string type)
    {
        m_requestType = type;
    }
    string getType()
    {
        return m_requestType;
    }
    void setContent(string content)
    {
        m_requestContent = content;
    }
    string getContent()
    {
        return m_requestContent;
    }
    void setNumber(int n)
    {
        m_number = n;
    }
    int getNumber()
    {
        return m_number;
    }
private:
    string m_requestType;//請求類型
    string m_requestContent;//請求內容
    int m_number;//數量
};
 
#endif // REQUEST_H


Manager處理請求的抽象類：

#ifndef MANAGER_H
#define MANAGER_H
#include <string>
#include <iostream>
#include "Request.h"
using namespace std;
 
//Handler抽象類
class Manager
{
public:
    ~Manager()
    {
        if(m_superior != NULL)
            delete m_superior;
    }
    //處理請求接口
    virtual void requestApplication(Request* request) = 0;
    //設置上級
    void setSuperior(Manager* superior)
    {
        m_superior = superior;
    }
protected:
    Manager(string name)
    {
        m_name = name;
        m_superior = NULL;
    }
protected:
    string m_name;//管理者姓名
    Manager* m_superior;//管理者的上級
};
 
#endif // MANAGER_H


CommonManager處理請求的具體類：

#ifndef COMMONMANAGER_H
#define COMMONMANAGER_H
#include "Manager.h"
 
//Handler具體實現類，處理請求的具體對象，經理
class CommonManager : public Manager
{
public:
    CommonManager(string name):Manager(name){}
    //請求處理函數
    void requestApplication(Request* request)
    {
        if(request->getType() == "ask for leave" && request->getNumber() <= 2)
        {
            cout << m_name << ":" << request->getContent() << " number:"
                 << request->getNumber() << "day    approval" << endl;
        }
        else
        {
            if(m_superior != NULL)
                m_superior->requestApplication(request);
        }
    }
};
 
#endif // COMMONMANAGER_H


Majordomo處理請求的具體類：

#ifndef MAJORDOMO_H
#define MAJORDOMO_H
#include "Manager.h"
 
//Handler具體實現類，處理請求的具體對象，技術總監
class Majordomo : public Manager
{
public:
    Majordomo(string name):Manager(name){}
    //處理請求函數
    void requestApplication(Request* request)
    {
        if(request->getType() == "ask for leave" && request->getNumber() <= 5)
        {
            cout << m_name << ":" << request->getContent() << " number:"
                 << request->getNumber() << "day    approval" << endl;
        }
        else
        {
            if(m_superior != NULL)
                m_superior->requestApplication(request);
        }
    }
};
 
#endif // MAJORDOMO_H


GeneralManager處理請求的具體類：

#ifndef GENERALMANAGER_H
#define GENERALMANAGER_H
#include "Manager.h"
 
//Handler具體實現類，處理請求的具體對象，總經理
class GeneralManager : public Manager
{
public:
    GeneralManager(string name):Manager(name){}
    //處理請求函數
    void requestApplication(Request* request)
    {
        if(request->getType() == "ask for leave")
        {
            cout << m_name << ":" << request->getContent() << " number:"
                 << request->getNumber() << "day    approval" << endl;
        }
        else if(request->getType() == "ask for a raise" && request->getNumber() <= 1000)
        {
            cout << m_name << ":" << request->getContent() << " number:"
                 << request->getNumber() << "    approval" << endl;
        }
        else if(request->getType() == "ask for a raise" && request->getNumber() > 1000)
        {
            cout << m_name << ":" << request->getContent() << " number:"
                 << request->getNumber() << "    rejected" << endl;
        }
    }
};
 
#endif // GENERALMANAGER_H


客戶調用程序：

#include "Manager.h"
#include "CommonManager.h"
#include "Majordomo.h"
#include "GeneralManager.h"
 
int main()
{
    Manager* li = new CommonManager("Li");
    Manager* zhang = new Majordomo("zhang");
    Manager* wang = new GeneralManager("wang");
 
    li->setSuperior(zhang);//設置CommonManager上級為Majordomo
    zhang->setSuperior(wang);//設置Majordomo上級為GeneralManager
 
    Request request1;
    request1.setType("ask for leave");//請假
    request1.setContent("xiaoming ask for leave");
    request1.setNumber(1);
    li->requestApplication(&request1);
 
    Request request2;
    request2.setType("ask for a raise");//加薪
    request2.setContent("xiaohong ask for a raise");
    request2.setNumber(1000);
    li->requestApplication(&request2);
 
    Request request3;
    request3.setType("ask for a raise");//加薪
    request3.setContent("xiaozhang ask for a raise");
    request3.setNumber(2000);
    li->requestApplication(&request3);
 
    Request request4;
    request4.setType("ask for leave");//請假
    request4.setContent("xiaozhang ask for leave");
    request4.setNumber(5);
    li->requestApplication(&request4);
 
    delete li,zhang,wang;
    return 0;
}


本文出自 “生命不息，奮鬥不止” 博客，謝絕轉載！

設計模式（十八）——職責鏈模式

相關推薦

設計模式（十八）——職責鏈模式

設計模式 職責鏈模式設計模式（十八）——職責鏈模式一、職責鏈模式簡介1、職責鏈模式簡介職責鏈模式（Chain Of Responsibility）使多個對象都有機會處理請求，從而避免請求的發送者和接收者之間的耦合。將可能處理請求的對象連成一條鏈，並沿著這條鏈傳遞請求，直到有一個對象處理請求為止。2、職責連模式

軟體設計模式學習（十七）職責鏈模式

> 系統中如果存在多個物件可以處理一個同一請求，可以通過職責鏈模式將這些處理請求的物件連成一條鏈，讓請求沿著該鏈進行傳遞。如果鏈上的物件可以處理該請求則進行處理，否則將請求轉發給下家處理 ## 模式動機 很多情況下，可以處理某個請求的物件不止一個，如大學裡的獎學金審批，學生先向輔導員提交審批表，輔

設計模式（十八）---模板方法模式

strac string package style prim res 不同的 好的 clas 1、簡介 　　模板方法模式是類的行為模式。準備一個抽象類，將部分邏輯以具體方法以及具體構造函數的形式實現，然後聲明一些抽象方法來迫使子類實現剩余的邏輯。 　　不同的子類可以以不同

設計模式（十八）橋接模式

橋接模式（Bridge）,將抽象部分與他的實現部分分離，使他們都可以獨立地變化 類圖的來源 http://img5.imgtn.bdimg.com/it/u=1548947177,2280329040&fm=26&gp=0.jpg public abstract

淺談Java設計模式（十七）責任鏈模式（Chain of Responsibility）

前言： 接下來我們將要談談責任鏈模式，有多個物件，每個物件持有對下一個物件的引用，這樣就會形成一條鏈，請求在這條鏈上傳遞，直到某一物件決定處理該請求。但是發出者並不清楚到底最終那個物件會處理該請求，所

設計模式（十八）——橋接模式

橋接模式（Bridge） 橋接模式，將抽象部分與它的實現部分分離，使它們都可以獨立地變化。 程式碼 1.程式碼如下： 手機軟體抽象類 using System; namespace Bridge

命令模式 Command 行為型 設計模式（十八）

命令模式（Command） 請分析上圖中這條命令的涉及到的角色以及執行過程，一種可能的理解方式是這樣子的： 涉及角色為：大狗子和大狗子他媽 過程為：大狗子他媽角色 呼叫 大狗子的“回家吃飯”方法 引子 package c

Android設計模式（十八）-組合模式

組合模式，也稱作部分整體模式。是結構型設計模式之一。組合模式畫成圖就是資料結構中的樹結構，有一個根節點，然後有很多分支。將最頂部的根節點叫做根結構件，將有分支的節點叫做枝幹構件，將沒有分支的末端節點叫做葉子構件. 定義 將物件組合成樹形結構以表示“部

設計模式（十五）——橋接模式

不用 java 高層 ext 部分 獨立 lib 類型 ray 1.描述 將橋接部分與他的實現部分分離，是他們都可以獨立的變化。 2.模式的使用 ·抽象(Abstraction)：是一個抽象類，該抽象類含有Implementor的聲明，即維護一個Implementor類型

設計模式（十七）——模板方法模式

ring next pri cut 限制 pack [] eat 模式 1.描述 定義一個操作中算法的骨架，而將一些步驟延伸到子類當中。模板方法使子類可以不改變一個算法的結構即可重定義該算法的某些特定步驟。 2.模式的使用 ·抽象模板(Abstract Template)：

設計模式（十二）—— 享元模式

方便 表示 復雜 優缺點 強制 port n) 使用場景 nfa 模式簡介 運用共享技術有效地支持大量細粒度地對象。 通常情況下，面向對象技術可以增強系統地靈活性及可擴展性，在系統開發過程中，我們會不斷地增加類和對象。當對象數量過多時，將會帶來系統開銷過高、性能下降等

設計模式（十一）建造者模式

用程式畫一個小人，這在遊戲程式裡非常常見。現在簡單一點，要求是小人要有頭、身體、兩手、兩腳就可以了。 第一版  Pen p = new Pen (Color.Yellow); Graphics gThin = pictureBox1.CreateGraphics();

設計模式（十七）橋接模式

橋接模式（Bridge）,將抽象部分與他的實現部分分離，使他們都可以獨立地變化 類圖的來源 public abstract class Implementor { public ab

我與C++設計模式（十五）——觀察者模式

毋庸置疑，observer模式的地位是十分重要的，此處省略一些套話，那麼什麼是observer模式，他在幫我們解決什麼問題或者說他在面對什麼情形進行設計的。 observer模式要解決的問題是，建立一個一對多的依賴關係，並且做到當“一”變化的時候，“多”能夠及時作出相應的響

Java設計模式（十五）----觀察者模式

觀察者模式 一、定義 二、結構 具體案例 推模型和拉模型 三、Java提供的對觀察者模式的支援 Observer介面 Observable類 一、定義 觀察者模式是物件的行為模式，又叫釋出-訂閱(Publish/Subscribe)模式

Android設計模式（十一）-觀察者模式

觀察者模式是一種使用頻率非常高的設計模式，最常用的地方就是訂閱-釋出系統。 這個模式的重要作用就是將觀察者和被觀察者解耦，使他們之間的依賴更小甚至沒有。 定義 定義物件一種一對多的依賴關係，使得每當一個物件改變狀態，則所有依賴於他的物件都會得到通知

設計模式（十一）：代理模式

優點： 　　① 將代理物件和真實被呼叫的目標物件分離，降低了耦合度，提高了擴充套件性。 　　② 保護和增強目標物件。 缺點： 　　① 增加了代理類，請求速度變慢，增加系統複雜性。 適用範圍： 　　① 安全代理，用來控制真實物件的訪問許可權。 　　② 智慧代理，呼叫真實物件時，代理處理另外一些

我所理解的設計模式（C++實現）——責任鏈模式（Chain Of Responsibility Pattern）

概述：      辛辛苦苦了工作了一年，終於可以加薪了，向主管提交了加薪申請，主管一看不得了，自己職權不夠，批不了，主管把申請上交總監，總監發現自己也批不了，申請到了總經理手中，總經理一看，小夥子口氣不小了，有膽識敢申請，先來談下心。預知後事如何，請看下回分解。     

Java設計模式（十二）----享元模式

享元模式 一、 概念 二、享元的用途 三、結構和分類 1、單純享元模式　 2、複合享元模式 四、享元模式的優缺點 一、概念 　Flyweight在拳擊比賽中指最輕量級，即“蠅量級”或“雨量級”，這裡選擇使用“享元模式”的意譯，是因為這

設計模式（十四）中介者模式

前言 寫了很多篇設計模式的文章，才發現沒有講關於設計模式的分類，那麼這一篇就補上這一內容，順便帶來中介者模式的講解。並與此前講過的代理模式和外觀模式做對比。 1.設計模式的分類 GoF提出的設計模式總共有23種，根據目的準則分類分為三大類：