設計模式之職責鍊模式(Chain of Responsibility)摘錄

23種GOF設計模式一般分為三大類：建立型模式、結構型模式、行為模式。

建立型模式抽象了執行個體化過程，它們幫助一個系統獨立于如何建立、組合和表示它的那些對象。一個類建立型模式使用繼承改變被執行個體化的類，而一個對象建立型模式将執行個體化委托給另一個對象。建立型模式有兩個不斷出現的主旋律。第一，它們都将關于該系統使用哪些具體的類的資訊封裝起來。第二，它們隐藏了這些類的執行個體是如何被建立和放在一起的。整個系統關于這些對象所知道的是由抽象類所定義的接口。是以，建立型模式在什麼被建立，誰建立它，它是怎樣被建立的，以及何時建立這些方面給予了很大的靈活性。它們允許用結構和功能差别很大的“産品”對象配置一個系統。配置可以是靜态的(即在編譯時指定)，也可以是動态的(在運作時)。

結構型模式涉及到如何組合類和對象以獲得更大的結構。結構型類模式采用繼承機制來組合接口或實作。結構型對象模式不是對接口和實作進行組合，而是描述了如何對一些對象進行組合，進而實作新功能的一些方法。因為可以在運作時刻改變對象組合關系，是以對象組合方式具有更大的靈活性，而這種機制用靜态類組合是不可能實作的。

行為模式涉及到算法和對象間職責的配置設定。行為模式不僅描述對象或類的模式，還描述它們之間的通信模式。這些模式刻畫了在運作時難以跟蹤的複雜的控制流。它們将使用者的注意力從控制流轉移到對象間的聯系方式上來。行為類模式使用繼承機制在類間分派行為。行為對象模式使用對象複合而不是繼承。一些行為對象模式描述了一組對等的對象怎樣互相協作以完成其中任一個對象都無法單獨完成的任務。

建立型模式包括：1、FactoryMethod(工廠方法模式)；2、Abstract Factory(抽象工廠模式)；3、Singleton(單例模式)；4、Builder(建造者模式、生成器模式)；5、Prototype(原型模式).

結構型模式包括：6、Bridge(橋接模式)；7、Adapter(擴充卡模式)；8、Decorator(裝飾模式)；9、Composite(組合模式)；10、Flyweight(享元模式)；11、Facade(外觀模式)；12、Proxy(代理模式).

行為模式包括：13、TemplateMethod(模闆方法模式)；14、Strategy(政策模式)；15、State(狀态模式)；16、Observer(觀察者模式)；17、Memento(備忘錄模式)；18、Mediator(中介者模式)；19、Command(指令模式)；20、Visitor(通路者模式)；21、Chain of Responsibility(責任鍊模式)；22、Iterator(疊代器模式)；23、Interpreter(解釋器模式).

Factory Method：定義一個用于建立對象的接口，讓子類決定将哪一個類執行個體化。Factory Method使一個類的執行個體化延遲到其子類。

Abstract Factory：提供一個建立一系列相關或互相依賴對象的接口，而無需指定他們具體的類。

Singleton：保證一個類僅有一個執行個體，并提供一個通路它的全局通路點。

Builder：将一個複雜對象的建構與它的表示分離，使得同樣的建構過程可以建立不同的表示。

Prototype：用原型執行個體指定建立對象的種類，并且通過拷貝這個原型來建立新的對象。

Bridge：将抽象部分與它的實作部分分離，使它們都可以獨立地變化。

Adapter：将一個類的接口轉換成客戶希望的另外一個接口。Adapter模式使得原本由于接口不相容而不能一起工作的那些類可以一起工作。

Decorator：動态地給一個對象添加一些額外的職責。就擴充功能而言， Decorator模式比生成子類方式更為靈活。

Composite：将對象組合成樹形結構以表示“部分-整體”的層次結構。Composite使得客戶對單個對象和複合對象的使用具有一緻性。

Flyweight：運用共享技術有效地支援大量細粒度的對象。

Facade：為子系統中的一組接口提供一個一緻的界面， Facade模式定義了一個高層接口，這個接口使得這一子系統更加容易使用。

Proxy：為其他對象提供一個代理以控制對這個對象的通路。

Template Method：定義一個操作中的算法的骨架，而将一些步驟延遲到子類中。Template Method使得子類可以不改變一個算法的結構即可重定義該算法的某些特定步驟。

Strategy：定義一系列的算法,把它們一個個封裝起來, 并且使它們可互相替換。本模式使得算法的變化可獨立于使用它的客戶。

State：允許一個對象在其内部狀态改變時改變它的行為。對象看起來似乎修改了它所屬的類。

Observer：定義對象間的一種一對多的依賴關系,以便當一個對象的狀态發生改變時,所有依賴于它的對象都得到通知并自動重新整理。

Memento：在不破壞封裝性的前提下，捕獲一個對象的内部狀态，并在該對象之外儲存這個狀态。這樣以後就可将該對象恢複到儲存的狀态。

Mediator：用一個中介對象來封裝一系列的對象互動。中介者使各對象不需要顯式地互相引用，進而使其耦合松散，而且可以獨立地改變它們之間的互動。

Command：将一個請求封裝為一個對象，進而使你可用不同的請求對客戶進行參數化；對請求排隊或記錄請求日志，以及支援可取消的操作。

Visitor：表示一個作用于某對象結構中的各元素的操作。它使你可以在不改變各元素的類的前提下定義作用于這些元素的新操作。

Chain of Responsibility：為解除請求的發送者和接收者之間耦合，而使多個對象都有機會處理這個請求。将這些對象連成一條鍊，并沿着這條鍊傳遞該請求，直到有一個對象處理它。

Iterator：提供一種方法順序通路一個聚合對象中各個元素, 而又不需暴露該對象的内部表示。

Interpreter：給定一個語言, 定義它的文法的一種表示，并定義一個解釋器, 該解釋器使用該表示來解釋語言中的句子。

Chain of Responsibility：(1)、意圖：使多個對象都有機會處理請求，進而避免請求的發送者和接收者之間的耦合關系。将這些對象連成一條鍊，并沿着這條鍊傳遞該請求，直到有一個對象處理它為支。

(2)、适用性：A、有多個的對象可以處理一個請求，哪個對象處理該請求運作時刻自動确定。B、你想在不明确指定接收者的情況下，向多個對象中的一個送出一個請求。C、可處理一個請求的對象集合應被動态指定。

(3)、優缺點：A、降低耦合度：該模式使得一個對象無需知道是其它哪一個對象處理其請求。對象僅需知道該請求會被”正确”地處理。接收者和發送者都沒有對方的明确的資訊，且鍊中的對象不需知道鍊的結構。結果是，職責鍊可簡化對象的互相連接配接。它們僅需保持一個指向其後繼者的引用，而不需保持它所有的候選接收者的引用。B、增強了給對象指派職責(Responsibility)的靈活性：當在對象中分派職責時，職責鍊給你更多的靈活性。你可以通過在運作時刻對該鍊進行動态的增加或修改來增加或改變處理一個請求的那些職責。你可以将這種機制與靜态的特例化處理對象的繼承機制結合起來使用。C、不保證被接收：既然一個請求沒有明确的接收者，那麼就不能保證它一定會被處理------該請求可能一直到鍊的末端都得不到處理。一個請求也可能因為鍊沒有被正确配置而得不到處理。

(4)、相關模式：職責鍊常與Composite一起使用。這種情況下，一個構件的父構件可作為它的後繼。

(5)、Chain ofResponsibility模式中ConcreteHandler将自己的後繼對象(向下傳遞消息的對象)記錄在自己的後繼表中，當一個請求到來時，ConcreteHandler會先檢檢視自己有沒有比對的處理程式，如果有就自己處理，否則傳遞給它的後繼。Chain of Responsibility模式的最大的一個優點就是給系統降低了耦合性，請求的發送者完全不必知道該請求會被哪個應答對象處理，極大地降低了系統的耦合性。

示例代碼1：

#include <iostream>
#include <string>
#include <vector>

using namespace std;

//請求
class Request
{
public:
	string m_strContent;
	int m_nNumber;
};

//管理者
class Manager
{
protected:
	Manager* manager;
	string name;
public:
	Manager(string temp)
	{
		name = temp;
	}

	void SetSuccessor(Manager* temp)
	{
		manager = temp;
	}

	virtual void GetRequest(Request* request) = 0;
};

//經理
class CommonManager : public Manager
{
public:
	CommonManager(string strTemp) : Manager(strTemp) {}

	virtual void GetRequest(Request* request)
	{
		if (request->m_nNumber >= 0 && request->m_nNumber < 10)
			cout<<name<<"處理了"<<request->m_nNumber<<"個請求"<<endl;
		else
			manager->GetRequest(request);
	}
};

//總監
class MajorDomo : public Manager
{
public:
	MajorDomo(string name) : Manager(name) {}

	virtual void GetRequest(Request* request)
	{
		if (request->m_nNumber >= 10)
			cout<<name<<"處理了"<<request->m_nNumber<<"個請求"<<endl;
	}
};

//用戶端
int main()
{
	Manager* common = new CommonManager("張經理");
	Manager* major = new MajorDomo("李總監");

	common->SetSuccessor(major);

	Request* req = new Request();
	req->m_nNumber = 33;
	common->GetRequest(req);

	req->m_nNumber = 3;
	common->GetRequest(req);

	/*result
		李總監處理了33個請求
		張經理處理了3個請求
	*/

	return 0;
}

示例代碼2：

Handle.h:

#ifndef _HANDLE_H_
#define _HANDLE_H_

class Handle
{
public:
	virtual ~Handle();
	virtual void HandleRequest() = 0;
	void SetSuccessor(Handle* succ);
	Handle* GetSuccessor();
protected:
	Handle();
	Handle(Handle* succ);
private:
	Handle* _succ;
};

class ConcreteHandleA : public Handle
{
public:
	ConcreteHandleA();
	~ConcreteHandleA();
	ConcreteHandleA(Handle* succ);
	void HandleRequest();
protected:
private:
};

class ConcreteHandleB : public Handle
{
public:
	ConcreteHandleB();
	~ConcreteHandleB();
	ConcreteHandleB(Handle* succ);
	void HandleRequest();
protected:
private:
};

#endif//~_HANDLE_H_

Handle.cpp:

#include "Handle.h"
#include <iostream>

using namespace std;

Handle::Handle()
{
	_succ = 0;
}

Handle::~Handle()
{
	delete _succ;
}

Handle::Handle(Handle* succ)
{
	this->_succ = succ;
}

void Handle::SetSuccessor(Handle* succ)
{
	_succ =  succ;
}

Handle* Handle::GetSuccessor()
{
	return _succ;
}

void Handle::HandleRequest()
{

}

ConcreteHandleA::ConcreteHandleA()
{

}

ConcreteHandleA::ConcreteHandleA(Handle* succ) : Handle(succ)
{

}

ConcreteHandleA::~ConcreteHandleA()
{

}

void ConcreteHandleA::HandleRequest()
{
	if (this->GetSuccessor() != 0) {
		cout<<"ConcreteHandleA 我把處理權給後繼節點 ..."<<endl;
		this->GetSuccessor()->HandleRequest();
	} else
		cout<<"ConcreteHandleA 沒有後繼了， 我必須自己處理 ..."<<endl;
}

ConcreteHandleB::ConcreteHandleB()
{

}

ConcreteHandleB::ConcreteHandleB(Handle* succ) : Handle(succ)
{

}

ConcreteHandleB::~ConcreteHandleB()
{

}

void ConcreteHandleB::HandleRequest()
{
	if (this->GetSuccessor() != 0) {
		cout<<"ConcreteHandleB 我把處理權給後繼節點 ..."<<endl;
		this->GetSuccessor()->HandleRequest();
	} else
		cout<<"ConcreteHandleB 沒有後繼了，我必須自己處理 ..."<<endl;
}

main.cpp:

#include "Handle.h"
#include <iostream>

using namespace std;

int main()
{
	Handle* h1 = new ConcreteHandleA();
	Handle* h2 = new ConcreteHandleB();

	h1->SetSuccessor(h2);
	h1->HandleRequest();

	/*result
		ConcreteHandleA 我把處理權給後繼節點 ...
		ConcreteHandleB 沒有後繼了，我必須自己處理 ...
	*/

	return 0;
}

職責鍊模式結構圖：

設計模式之職責鍊模式(Chain of Responsibility)摘錄

參考文獻：

1、《大話設計模式C++》

2、《設計模式精解----GoF23種設計模式解析》

3、《設計模式----可複用面向對象軟體的基礎》

設計模式之職責鍊模式(Chain of Responsibility)摘錄

繼續閱讀

指令模式-Spring架構JdbcTemplate

設計模式的五大設計原則設計模式的五大設計原則

深入淺出設計模式 ------ Abstract Factory(抽象工廠)

Connector pattern（基于c++ poco庫分析）

Scala 設計模式：結構型模式

C語言和設計模式（1.4單件模式）

Design patterns IV : Decorator/Wrapper Pattern

一個簡單的工廠方法模式

徹底搞懂設計模式DesignPattern-工廠模式-簡單工廠-工廠方法-靜态工廠-抽象工廠

研磨設計模式筆記之簡單工廠模式1.不用模式的解決方案2.帶模式的解決方案3.思考簡單工廠

設計模式讀書筆記之裝飾器模式(Decorator)

【設計模式基礎】行為模式 - 3 - 職責鍊(Chain of responsibility)1. 模式意圖2. 模式定義3. 模式實作4. 模式應用

設計模式學習筆記(十四)—Command模式

ant design pro 5_問問Design | 網課錄播+彩蛋，答應我這次别再錯過了！

Java 中的靜态代理與動态代理