小時候寫日記都是這麼寫的:上午七點起牀,八點以前洗臉刷牙吃早飯,十二點以前好好上課,中午一點,吃午餐,下午兩點到六點,上課,下課,找請假,明天媽媽要帶我去姥姥家,九點以前,看動畫片,九點鐘,收拾去姥姥家的東西,十點之後,睡覺。html
咱們把請假這塊在充實一下:找班長請假,班長只能請半天,不然班長向老師申請,若是請假時間超過一週,老師要跟副年級主任請示,若是請假超出一個月,主任要跟年級正主任請示,而後被批准,或不被批准。編程
若是用編程語言描述這兩件事情,應該是這個樣子的。設計模式
- public class DayWork
- {
- private int hour;
-
-
- public void writeProgram()
- {
- if (hour < 7)
- {
- System.out.println("當前時間:" + hour + "點 睡覺");
- }
- else if (hour = 7)
- {
- System.out.println("當前時間:" + hour + "洗臉刷牙吃早飯");
- }
- else if (hour < 12)
- {
- System.out.println("當前時間:" + hour + "點 好好上課");
- }
- else if(hour=1)
- {
- System.out.println("當前時間:" + hour + "點 吃午餐");
-
- }
- else if(hour<18)
- {
- System.out.println("當前時間:" + hour + "點 好好學習");
-
- }
- }
-
- public int getHour()
- {
- return hour;
- }
-
- public void setHour(int hour)
- {
- this.hour = hour;
- }
-
-
- }
- //客戶端代碼
- public class Main
- {
- public static void main(String[] args)
- {
- DayWork work = new Work();
- work.setHour(9);
- work.writeProgram();
- work.setHour(10);
- work.writeProgram();
- work.setHour(12);
- work.writeProgram();
- work.setHour(13);
- work.writeProgram();
- work.setHour(14);
- work.writeProgram();
-
- }
- }
而請假的代碼和這個差很少,if 請半天,班長請,else if 一週之內,老師請 else if 一個月之內 副主任請,else 超過一個月 主任請。app
但是,拿日記例子來看,過多的if分支並非一件好事,它首先不知足開閉原則,一旦須要修改整個IF語句都須要修改,責任沒有費解,也不符合單一職責原則,咱們但願分解整個行爲,把狀態的判斷邏輯轉移到表示不一樣狀態的一系列類當中,把複雜的判斷邏輯簡化,這就是咱們所說的狀態模式。編程語言
狀態模式結構圖:
ide
狀態模式代碼實現:oop
- //State類,抽象狀態類,定義一個接口以封裝與Context的一個特定狀態相關的行爲
- public interface State
- {
- public void handle(Context context);
- }
- //ConcreteState類,具體狀態,每個子類實現一個與Context的一個狀態相關的行爲。
- public class ConcreteStateA implements State
- {
- public void handle(Context context)
- {
- context.setState(new ConcreteStateB());
- }
- }
- public class ConcreteStateB implements State
- {
- public void handle(Context context)
- {
- context.setState(new ConcreteStateA());
- }
- }
- //Context類,維護一個ConcreteState子類的實例,這個實例定義當前的狀態
- public class Context
- {
- private State state;
-
- public Context(State state)
- {
- this.state = state;
- }
-
- public void request()
- {
- state.handle(this);
- }
-
- public State getState()
- {
- return state;
- }
-
- public void setState(State state)
- {
- this.state = state;
- System.out.println("當前狀態:" + state.getClass().getName());
- }
- }
- //客戶端代碼
- public class Main
- {
- public static void main(String[] args)
- {
- Context context = new Context(new ConcreteStateA());
-
- context.request();
- context.request();
- context.request();
- context.request();
- }
- }
狀態模式將特定的狀態相關的行爲都放入一個對象中,因爲全部與狀態相關的代碼都存在於某個ConcreteState中,因此經過定義新的子類能夠很容易地增長新的狀態和轉換。學習
並且,狀態模式把各類狀態轉移邏輯分佈到State的子類之間,來減小相互間的依賴。動畫
請假問題也是一個很複雜的條件表達式,安理說用狀態模式是可使用的。this
可是,這裏有一個問題,就是,若是班長請假了,用狀態模式的道理講,就是其餘學生都請不了假了,也就是若是狀態模式中任何一環缺失的話,這個事件都沒法進行下去,怎麼辦?
這就須要咱們的職責鏈模式。
結構圖:
代碼實現:
- <pre name="code" class="html">// Chain of Responsibility pattern -- Structural example
- using System;
-
- // "Handler"
- abstract class Handler
- {
- // Fields
- protected Handler successor;
-
- // Methods
- public void SetSuccessor( Handler successor )
- {
- this.successor = successor;
- }
- abstract public void HandleRequest( int request );
- }
-
- // "ConcreteHandler1"
- class ConcreteHandler1 : Handler
- {
- // Methods
- override public void HandleRequest( int request )
- {
- if( request >= 0 && request < 10 )
- Console.WriteLine("{0} handled request {1}",
- this, request );
- else
- if( successor != null )
- successor.HandleRequest( request );
- }
- }
-
- // "ConcreteHandler2"
- class ConcreteHandler2 : Handler
- {
- // Methods
- override public void HandleRequest( int request )
- {
- if( request >= 10 && request < 20 )
- Console.WriteLine("{0} handled request {1}",
- this, request );
- else
- if( successor != null )
- successor.HandleRequest( request );
- }
- }
-
- // "ConcreteHandler3"
- class ConcreteHandler3 : Handler
- {
- // Methods
- override public void HandleRequest( int request )
- {
- if( request >= 20 && request < 30 )
- Console.WriteLine("{0} handled request {1}",
- this, request );
- else
- if( successor != null )
- successor.HandleRequest( request );
- }
- }
-
- /**//// <summary>
- /// Client test
- /// </summary>
- public class Client
- {
- public static void Main( string[] args )
- {
- // Setup Chain of Responsibility
- Handler h1 = new ConcreteHandler1();
- Handler h2 = new ConcreteHandler2();
- Handler h3 = new ConcreteHandler3();
- h1.SetSuccessor(h2);
- h2.SetSuccessor(h3);
-
- // Generate and process request
- int[] requests = { 2, 5, 14, 22, 18, 3, 27, 20 };
-
- foreach( int request in requests )
- h1.HandleRequest( request );
-
- }
- }
職責鏈模式(Chain of Responsibility):使多個對象都有機會處理請求,從而避免請求的發送者和接受者之間的耦合關係。將這個對象練成一條鏈,並沿着這條鏈傳遞該請求,直到有一個對象處理它爲止。
從代碼中咱們能夠看出,職責鏈模式的鏈式在客戶端鏈接的,也就是說,若是咱們請假,請假制度一旦改變,好比說咱們不須要班長,或者是先請求老師後直接請求主任或者中間多了一個環節,都是很容易實現的,因此,職責鏈模式要比狀態模式靈活不少。
可是,這時候是否是有人要問,均可以解決If分支過多,是否是職責鏈模式比狀態模式好呢,仍是那句話,存在即合理,職責鏈模式雖然靈活,可是他過於靈活,咱們在使用時須要肯定下一個對象是誰,在屢次設置的時候很容易出問題,因此,這時候用狀態模式就比較好,就像咱們記錄一天的行爲,事情已經發生,若是用職責鏈模式就顯得多此一舉了。
從定義來看,狀態模式是一個對象的內在狀態發生改變(一個對象,相對比較穩定,處理完一個對象下一個對象的處理通常都已肯定),而職責鏈模式是多個對象之間的改變(多個對象之間的話,就會出現某個對象不存在的如今,就像請假例子中的班長或者老師可能缺勤),這也說明他們兩個模式處理的狀況不一樣。
其實,這兩個設計模式最大的區別就是狀態模式是讓各個狀態對象本身知道其下一個處理的對象是誰,即在編譯時便設定好了的;
而職責鏈模式中的各個對象並不指定其下一個處理的對象究竟是誰,只有在客戶端才設定。用咱們通俗的編程語言來講,就是
狀態模式:
至關於If else if else;
設計路線:各個State類的內部實現(至關於If,else If內的條件)
執行時經過State調用Context方法來執行。
職責鏈模式:
至關於Swich case
設計路線:客戶設定,每一個子類(case)的參數是下一個子類(case)。
使用時,向鏈的第一個子類的執行方法傳遞參數就能夠。
就像對設計模式的總結,有的人採用的是狀態模式,從頭至尾,提早必定定義好下一個處理的對象是誰,而我採用的是職責鏈模式,隨時都有可能調整鏈的順序