菜鳥工作滿三個月了，馬上要辦轉正首先，提了加薪的事情。菜鳥對經理如實說了自己的想法，希望公司能在轉正時增加工資待遇，經理肯定了菜鳥的能力，但是加薪做不了主，但是幫他向上提一提。然後去找了人力資源總監，總監說這事他也做不了主，畢竟剛畢業的大學生加薪沒有先例，但總監說，等總經理來後，向總經理提一提這個事。最後，從經理那裡得到的訊息是，總經理不同意加薪，因為現在大學畢業生這麼多，隨便都能找得到，三個月就想加薪，不合適。
一、加薪**初步
無論加薪還是請假，都是一種申請。申請就應該有申請類別、申請內容和申請數量。
經理、總監、總經理都是管理者，他們在對『申請』處理時，需要做出判斷，是否有權決策
「管理者」類，裡面的『結果』方法比較長，加上有太多的分支判斷，者其實是非常不好的設計。因為你很難講當中還會不會增加其他的管理類別，比如專案經理、部門經理、人力總監、副總經理等等。哪就意味著都需要去更改這個類，這個類承擔了太多的責任，者違背了單一職責原則，增加新的管理類別，需要修改這個類，違背了開放-封閉原則。
應該如何下手去重構它呢？
可能會增加管理類別，那就意味著這裡容易變化，應該把這些公司管理者的類別做成管理者的子類，者就可以利用多型性來化解分支帶來的僵化。
那如何解決經理無權上報總監，總監無權再上報總經理這樣的功能呢？
它們之間有一定的關聯，把使用者的請求傳遞，知道可以解決這個請求為止。這就是『職責鏈模式』的意圖了。
二、職責鏈模式
職責鏈模式（chain of responsibility）:使多個物件都有機會處理請求，從而避免請求的傳送者和接收者之間的耦合關係。將這個物件連成一條鏈，並沿著這條鏈傳遞該請求，直到有乙個物件處理它為止。
這裡發出這個請求的客戶端並不知道這當中的哪乙個物件最終處理這個請求，這樣系統的更改可以在不影響客戶端的情況下動態地重新組織和分配責任。
三、職責鏈的好處
當客戶提交乙個請求時，請求是沿鏈傳遞直至有乙個concretehandler物件負責處理它。
這樣做的好處是請求者不用管哪個物件來處理，反正該請求會被處理就對了。
接收者和傳送者都沒有對方的明確資訊，且鏈中的物件自己也並不知道鏈的結構。結果是職責鏈可簡化物件的相互連線，它們僅需保持乙個指向其後繼者的引用，而不需保持它所有的候選接受者的引用。這也就大大降低了耦合度了。
隨時地增加或修改處理乙個請求的結構。增強了給物件指派職責的靈活性。
乙個請求極有可能到了鏈的末端都得不到處理，或者因為沒有正確配置而得不到處理，者就很糟糕了。
對於剛才的例子，最重要的有亮點，乙個是你需要事先給每個具體管理者設定他的上司是哪個類，也就是設定後繼者。另一點是你需要在每個具體管理者處理請求時，做出判斷，是可以處理這個請求，還是必須要『推卸責任』，轉移給後繼者去處理。
其實就是把現在寫的這個管理者類當中的那些分支，分解到每乙個具體的管理者類當中，然後利用事先設定的後繼者類實現請求處理的許可權問題。
四、加薪**重構
這的確是很好地解決了原來大量的分支判斷造成難以維護、靈活性差的問題。
設計模式之策略模式（二十二）
strategy 抽象策略類 所有策略類的父類，為所支援的策略演算法宣告了抽象方法。concretestrategy 具體策略類 實現了在抽象策略類中宣告的方法。context 環境類 負責使用演算法策略，其中維持了乙個抽象策略類的引用例項。strategy 抽象策略類 public abstrac...
大話設計模式 職責鏈模式
1.當客戶提交乙個請求時，請求是沿鏈傳遞直至有乙個concretehandler物件負責處理它 dp 2.接收者和傳送者都沒有對方的明確資訊，且鏈中的物件自己也並不知道鏈的結構。結果是職責鏈可簡化物件的相互連線，它們僅需保持乙個指向其後繼者的引用，而不需保持它所有的候選接受者的引用 dp 3.隨時隨...
設計模式（二十二） 策略模式
有時候物件需要按照某種策略改變行為，我們可以利用策略模式，將策略或演算法提取出來，作為單獨的類實現。使用策略模式，可以讓具體演算法和應用物件分離，方便的根據不同條件替換策略。下面舉乙個例子。我們有乙個計算器，它會按照快和慢兩種策略來計算結果。所以我們可以將策略封裝起來。public inte ce ...