我的Java設計模式責任鏈模式

今天來說說程式設計師小猿和產品就關於需求發生的故事。前不久，小猿收到了產品的需求。

產品經理：小猿，為了迎合大眾屌絲使用者的口味，我們要放一張圖，要**的。

小猿：......**？你大爺的，讓身為正義與純潔化身的我做這種需求，還**。

產品經理：誤會誤會，是放一張暴露一點點的，尺寸不大。

小猿：尼瑪~能說清楚些嗎，需求模稜兩可的。不幹，我要上報boss。

產品經理也一陣無語，這豆丁的事還上報boss。話說這上報也得走程式是吧，技術經理就不幹了，「憑什麼要跳過我，得經過我才能到boss」。咦~這一層一層上報就涉及到這次的責任鏈模式。

建立多個物件，使這些物件形成一條鏈，並沿著這條鏈傳遞請求，直到鏈上的某乙個物件決定處理此請求。

1）接收請求的物件連線成一條鏈，物件之間存在層級關係。

2）這些物件可處理請求，也可傳遞請求，直到有物件處理該請求。

責任鏈模式涉及到的角色如下所示：

- 具體處理者角色：實現或者繼承抽象這角色，具體邏輯根據實際的架構來定，後面會提到。

先來看抽象處理者角色**：

public abstract class handler 
// 處理請求傳遞，注意final，子類不可重寫
public final void handlemessage(demand demand) else else }}
public void setnexthandler(handler handler) 
// 抽象方法，子類實現
public abstract void report(demand demand);
}

在抽象處理者角色定義了處理請求的抽象方法，以及下一級傳遞的物件方法，重點在handlemessage處理請求傳遞的方法，下面會解釋為什麼要這樣寫，繼續往下看。

下面是具體處理者角色，繼承抽象處理者角色，在我們情景中有兩個具體處理者，分別是技術經理和boss。

// 技術經理
public class technicalmanager extends handler 
@override
public void report(demand demand) 
}// boss
public class boss extends handler 
@override
public void report(demand demand) 
}

可以看到具體處理者的**很簡潔，重寫了report方法，實現各自的業務邏輯，這都歸功於父類中handlemessage這個方法。

兩個角色都定義好了，來看客戶端如何實現：

public class client 
}

需求：加一張露一點點的圖

technicalmanager：小猿我挺你，這個需求不幹

*************************===

需求：加一張露一點點的圖

technicalmanager：事情太嚴重，需報告上一級

boss：你們打一架吧，打贏的做決定

從結果可以看到，級別低的請求技術經理自己處理，級別高的傳遞給了下一級的boss，這樣就形成一條鏈，而這也是責任鏈的核心所在。注意，在請求的傳遞過程中，請求是不會發生變化的。需求不會從「加一張露一點點的圖」變成了「加一張**的圖」，這等著boss請到辦公室喝茶吧。

回頭看看上面的**，抽象類中定義了幾個方法，乙個是final修飾的handlemessage，乙個是抽象方法report，還有乙個是setnexthandler。這剛好是模板方法模式中的三個基本方法，分別是具體方法（抽象類宣告並實現，子類不實現）、抽象方法（抽象類宣告，子類必須實現）、鉤子方法（抽象類宣告並實現，子類可擴充套件）。handlemessage方法加了final修飾，子類不可重寫，而handlemessage正是把傳遞請求工作交給父類handler，子類不需要處理傳遞的工作。而report則是抽象方法，子類必須重寫該方法，子類處理請求的業務邏輯。setnexthandler是鉤子方法，在這裡我們並沒有實現。

這樣結合模板方法模式的好處在哪？首先加了handlemessage方法，把請求的傳遞判斷從子類中剝離出來，讓子類在report方法中專心處理請求的業務邏輯，做到了單一職責原則。再者是子類的實現變得簡單了，不需要進行傳遞的判斷，非常有利於快速擴充套件。

觀察者模式我在之前有些過，不了解的可以先看看。責任鏈模式和觀察者模式存在乙個共同點，就是傳遞責任鏈模式是一級一級的傳遞，形成一條鏈，鏈節點（處理者）之間是存在傳遞關係的。而觀察者模式的被觀察者向觀察者們的傳遞，並不是具體觀察者之間的傳遞，觀察者之間是不存在關聯的。拿小猿的經歷來說，在責任鏈模式中是請求從技術經理到boss，有層級關係，而對於觀察者模式是從被觀察者小猿發出，作為觀察者的技術經理和boss都會收到小猿的通知，是擴散式的，技術經理和boss並沒有層級關係。這是責任鏈模式和觀察者模式的區別，也是責任鏈模式的核心。

1）降低耦合度：客戶端不需要知道請求由哪個處理者處理，而處理者也不需要知道處理者之間的傳遞關係，由系統靈活的組織和分配。

2）良好的擴充套件性：增加處理者的實現很簡單，只需重寫處理請求業務邏輯的方法。

1）請求會從鏈頭髮出，直到有處理者響應，在責任鏈比較長的時候會影響系統效能。

2）請求遞迴，除錯排錯比較麻煩。

我的Java設計模式責任鏈模式

java設計模式責任鏈模式

Java設計模式責任鏈模式

我的設計模式之旅責任鏈模式

我的Java設計模式 責任鏈模式

java設計模式 責任鏈模式

Java設計模式 責任鏈模式

我的設計模式之旅 責任鏈模式

相關推薦

我的Java設計模式責任鏈模式

java設計模式責任鏈模式

Java設計模式責任鏈模式

我的設計模式之旅責任鏈模式