设计模式之职责链模式
生活随笔
收集整理的這篇文章主要介紹了
设计模式之职责链模式
小編覺得挺不錯的,現在分享給大家,幫大家做個參考.
定義：使多個對象都有機會處理請求，從而避免了請求的發送者和接收者之間的耦合關系。將這些對象連成一條鏈，并沿著這條鏈傳遞該請求，直到有對象處理它為止。
類型：行為類模式
類圖：
責任連模式的結構
??????? 責任連模式的類圖非常簡單，它由一個抽象地處理類和它的一組實現類組成：
- 抽象處理類：抽象處理類中主要包含一個指向下一處理類的成員變量nextHandler和一個處理請求的方法handRequest，handRequest方法的主要主要思想是，如果滿足處理的條件，則有本處理類來進行處理，否則由nextHandler來處理。
- 具體處理類：具體處理類主要是對具體的處理邏輯和處理的適用條件進行實現。
適用場景：
1、有多個的對象可以處理一個請求，哪個對象處理該請求運行時刻自動確定；
2、在不明確指定接收者的情況下，向多個對象中的一個提交一個請求；
3、處理一個請求的對象集合應被動態指定。
在職責鏈模式里，很多對象由每一個對象對其下家的引用而連接起來形成一條鏈。請求在這個鏈上傳遞，直到鏈上的某一個對象決定處理此請求。發出這個請求的客戶端并不知道鏈上的哪一個對象最終處理這個請求，這使得系統可以在不影響客戶端的情況下動態地重新組織鏈和分配責任。
?
職責鏈模式的主要優點在于可以降低系統的耦合度，簡化對象的相互連接，同時增強給對象指派職責的靈活性，增加新的請求處理類也很方便；其主要缺點在于不能保證請求一定被接收，且對于比較長的職責鏈，請求的處理可能涉及到多個處理對象，系統性能將受到一定影響，而且在進行代碼調試時不太方便。在大學里面當班干部，時常要向上級申請各方面的東西。譬如申請全班外出秋游，普通同學將申請表交給班長，班長簽字之后交給輔導員，輔導員批準之后上交到主任辦公室…就是這樣，一個請求（這里是一份申請表）有時候需要經過好幾個級別的處理者（這里是輔導員、主任）的審查才能夠最終被確定可行與否。
在這里表現出來的是一個職責鏈，即不同的處理者對同一個請求可能擔負著不同的處理方式、權限，但是我們希望這個請求必須到達最終拍板的處理者（否則秋游就沒戲了）。這種關系就很適合使用職責鏈模式了。
類圖結構如下：
?代碼實現如下：
?
?
?
?
?
測試結果：
1、對于每一個請求都需要遍歷職責鏈，性能是個問題；
2、抽象處理者 AbstractHandler 類中的 handleRequest() 方法中使用了遞歸，棧空間的大小也是個問題。
?
參考：http://blog.csdn.net/zhengzhb/article/details/7568676
http://haolloyin.blog.51cto.com/1177454/342166/
http://blog.csdn.net/qq7342272/article/details/6921524
http://blog.csdn.net/hguisu/article/details/7547231
http://www.cnblogs.com/java-my-life/archive/2012/05/28/2516865.html
http://www.cnblogs.com/xudong-bupt/p/3617860.html
轉載于:https://www.cnblogs.com/manmanlu/p/5732979.html
總結
以上是生活随笔為你收集整理的设计模式之职责链模式的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Native与H5交互的一些解决方法
- 下一篇： ios开发瀑布流框架的封装