23種設計模式 二十一 資料結構之職責鏈

23種設計模式(二)元件協作之模板方法

23種設計模式(三)元件協作之策略模式

23種設計模式(四)元件協作之觀察者模式

23種設計模式(五)單一職責之裝飾模式

23種設計模式(六)單一職責之橋模式

23種設計模式(七)物件建立之工廠方法

23種設計模式(八)物件建立之抽象工廠

23種設計模式(九)物件建立之原型模式

23種設計模式(十)物件建立之構建器

23種設計模式(十一)物件效能之單件模式

23種設計模式(十二)物件效能之享元模式

23種設計模式(十三)介面隔離之門面模式

23種設計模式(十四)介面隔離之**模式

23種設計模式(十五)介面隔離之介面卡

23種設計模式(十六)介面隔離之中介者

23種設計模式(十七)狀態變化之狀態模式

23種設計模式(十八)狀態變化之備忘錄

23種設計模式(十九)資料結構之組合模式

23種設計模式(二十)資料結構之迭代器

23種設計模式(二十一)資料結構之職責鏈

23種設計模式(二十二)行為變化之命令模式

23種設計模式(二十三)行為變化之訪問器

23種設計模式(二十四)領域規則之解析器

在軟體構建過程中, 乙個請求可能被多個物件處理,但是每個請求在執行時只能有乙個接受者,如果顯式指定,將必不可少地帶來請求傳送者與接受者的緊耦合。

如何使請求的傳送者不需要指定具體的接受者?讓請求的接受者自己在執行時決定來處理請求,從而使兩者解耦。

使多個物件都有機會處理請求,從而避免請求的傳送者和接收者之間的耦合關係。將這些物件連成一條鏈,並沿著這條鏈傳遞請求,直到有乙個物件處理它為止。

#include

#include
using
namespace std;
enum
class
requesttype
;class
reqest
requesttype getreqtype()
const
const string&
getdescription()
const};
class
chainhandler
protected
:virtual
bool
canhandlerequest
(const reqest & req)=0
;virtual
void
processrequest
(const reqest & req)=0
;public
:chainhandler()
void
setnextchain
(chainhandler *next)
void
handle
(const reqest & req)};
class
handler1
:public chainhandler
void
processrequest
(const reqest & req) override
};class
handler2
:public chainhandler
void
processrequest
(const reqest & req) override
};class
handler3
:public chainhandler
void
processrequest
(const reqest & req) override
};intmain()

應用了chain of responsibility模式後,物件的職責分派將更具靈活性。我們可以在執行時動態新增/修改請求的處理職責。

如果請求傳遞到職責鏈的末尾仍得不到處理,應該有乙個合理的預設機制。這也是每個接受物件的責任,而不是發出請求的物件的責任。

資料結構（二十一）

現在哈利 波特的手裡有一本教材，裡面列出了所有的變形魔咒和能變的動物。老師允許他自己帶乙隻動物去考場，要考察他把這只動物變成任意乙隻指定動物的本事。於是他來問你 帶什麼動物去可以讓最難變的那種動物 即該動物變為哈利 波特自己帶去的動物所需要的魔咒最長 需要的魔咒最短？例如 如果只有貓 鼠 魚，則顯然...

二十一 資料結構學習筆記 1

一.抽象資料型別 抽象資料型別 abstract data type,adt 是一些操作的集合。抽象資料型別是數學的抽象，在adt定義中根本沒涉及如何實現這些操作。例如 表 集合 圖及它們的操作，它們都可以看作抽象資料型別，就像整數 實數和布林量是資料型別一樣。整數 實數以及布林量有與它們相關的操作...

設計模式二十一之命令模式

2.模式的結構與實現 在軟體開發系統中，常常出現 方法的請求者 與 方法的實現者 之間存在緊密的耦合關係。這不利於軟體功能的擴充套件與維護。例如，想對行為進行 撤銷 重做 記錄 等處理都很不方便，因此 如何將方法的請求者與方法的實現者解耦？變得很重要，命令模式能很好地解決這個問題。在現實生活中，這樣...