C 設計模式之職責鏈

iron之職責鏈

需求:"iron"的建造一直沒有停止，現在單個部件是有的，但是在部件從工廠裡出來的時候，在組裝到一起之前，我們還是非常有必要對部件進行質量檢測，或者是其它個方面的檢測，又或者是設定部件標識資訊等等，這些操作可以是有序的（也可以是無序的）。

現在為了實現上面的所講的功能來進行演示，然過程中會發現問題，然後解決問題。這裡不多說了直接進入主題。

問題的發現：

首先我定義了乙個componentmodel類，它是要被檢驗的物件

///2

///部件

3///

4public

class

componentmodel57

public

intvalue813

}14 }

這裡先定義了乙個請求處理型別的列舉，下面要用到，這樣比用什麼字串或者是數字來作條件判斷要好很多。

///2

///請求的處理型別

3///

4public

enum

requeststate

再然後，我們再來定義檢驗componentmodel類的型別：

1
///2
///處理請求類1
3///
4public
class
concretehandlercaseone511
public
void
handlerequest(requeststate reqstate)
1220
break;21
case
requeststate.setdefvalue:
22                     _commodel.name = "
預設部件";
23//
執行處理
24break;25
default:26
27break;28
}30}31
}32///33
///處理請求類2
34///
35public
class
concretehandlercasetwo
3642
public
void
handlerequest(requeststate reqstate)
4351
break;52
case
requeststate.setdefvalue:
53                     _commodel.name = "
預設部件";
54//
執行處理
55break;56
default:57
58break;59
60}61}
62     }

定義了兩個型別，concretehandlercaseone和concretehandlercasetwo兩個型別，都是用來處理檢測componentmodel型別的，現在這些型別都齊全了我們來檢測一下吧。

1 componentmodel commodel = new
componentmodel();
2 concretehandlercaseone caseone = new
concretehandlercaseon(commodel);
3caseone.handlerequest(requeststate.check);
4 concretehandlercasetwo casetwo = new
concretehandlercasetw(commodel);
5 casetwo.handlerequest(requeststate.check);

對的，就是這樣，一次次的檢測下去，如果要檢測20次，並且都是不同的實現，那將非常可怕，**冗餘，而且請求呼叫方和處理方的耦合度也很大，那要怎麼樣讓**更精簡，並且還能有效的解耦，這裡就要用到職責鏈模式。

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

——gof

這裡要強調一下的是本篇的示例中並沒有完全遵從設計模式的定義，還是按照本文開始的功能需求來做的設計，當然了模式的核心不變。

設計模式的思想：

現在先對處理方進行抽象：

1
///2
///抽象處理者
3///
4public
abstract
class
handle511
public
abstract
void
handlerequest(requeststatereqstate,componentmodel commodel);
1213     }

既然有了抽象，那就得有具體的實現：

///2

///具體處理者

3///

4public

class

concretehandlera : handle522

}23}24

///25

///具體處理者

26///

27public

class

concretehandlerb : handle

2844

}45 }

這裡的型別應該只定義乙個的是為了讓大家看的更明白。

在這裡看抽象處理者handle型別，它裡面有個protected級別的變數successor，successor呢就代表著鍊錶中每一環的指標，指向誰呢？當然是指向下乙個處理者。

現在來看一下呼叫的**：

1 componentmodel commodel = new
componentmodel();
2 handle handlera = new
concretehandlera();
3 handle handlerb = new
concretehandlerb();
4handlera.setsuccessor(handlerb);
5 handlera.handlerequest(requeststate.check, commodel);

看上去已經不錯了，耦合度還是很大的，對於handlera的呼叫，還是再呼叫方直接呼叫的，這時需要乙個中間層，

看一下中間層的定義：

1
///2
///chainofresponsibility模式幫助類
3///
4public
class
corunit515
public
corunit(handle handle, componentmodel commodel)
1620
public
void
registerhandle(handle handle)
2126
else
2730}31
public
void
handlerequest(requeststate reqstate)
3235     }

通過加了一層，再來看一下呼叫方的**：

1 componentmodel commodel = new
componentmodel();
2 corunit corunit = new
corunit(commodel);
3 corunit.registerhandle(new
concretehandlera());
4 corunit.registerhandle(new
concretehandlerb());
5corunit.handlerequest(requeststate.check);6//
執行處理7//
commodel的一些處理

是不是感覺呼叫方，跟實際的處理方之間的關係變得很弱了，這樣目的也就達到了。

出處：

C 設計模式之職責鏈

C 設計模式之職責鏈模式

C 設計模式之職責鏈模式

設計模式之職責鏈模式

C 設計模式之職責鏈

C 設計模式之職責鏈模式

C 設計模式之 職責鏈模式

設計模式之職責鏈模式

相關推薦

C 設計模式之職責鏈模式