Dive into Spring framework -- 瞭解基本原理（二）－－設計模式－part1

比較巧，本身在接觸設計模式的時候，也剛開始學習spring，但惋惜的是，真的僅僅在學習「用」spring，天天都沉浸在會痛快的完成spring各類配置的快樂之中，但對成長無用。其實當初就清楚，spring框架中有大量設計模式，因而也下了代碼來看，設計模式其實沒那麼簡單，當初的學習也很皮毛，因此就沒有發現spring中的金礦。如今動手，裏面依然仍是金礦，但不要偷懶，讓它徹底腐爛。［這是對本身的告誡］

開頭上來就說到了spring跟設計模式，實際上，spring中的核心原則就是基於設計模式來構建的。這個時候繼續祭出《敏捷軟件開發》這本神書，結合裏面比較全面的和具體的設計模式來大致討論一下各類設計模式。（在此也建議將《敏捷》多看幾遍，雖然裏面用了c＋＋示例，但極易理解）

在學習和討論每種設計模式以前，都應該明確這樣幾個問題：

1）這個模式是什麼？

2）這個模式適應的場景是什麼，有何限制？

3）《敏捷》裏面是如何推出來用這個模式的？針對《敏捷》中的場景，如若不考慮這個模式，會如何出手？這種相似於範偉大師傅的神功，爲什麼降服不了「黑幫」？鐵定被打趴在地上的緣由，有考慮過麼？［範偉是俺的偶像］

Command模式

這個模式表面上看是個比較簡單的模式，這個是Bob的見解。他強調Command模式具備「功能分解的味道」。實際上在《design patterns》裏面command也是被歸類在行爲類的。通常的command接口定義：

public interface Command {

public void do();

}

從這個接口的角度講，咱們根本不知道它的主要意圖是什麼，因此在一個類實現這個接口以後，這個類的動做意圖，也一樣被這個接口給封裝起來了。Bob認爲從面向對象角度，這是違犯天條的行爲。但從上層抽象來講，這又是很好的屏蔽了上層（caller）對具體實現的依賴。因此說，命令模式是一種面向動做的獨立抽象，它能夠很好地處理輸入和動做調用方之間的隔離關係。

考慮到《敏捷》中的兩個例子，例1複印機程序，傳感器能夠在不須要知道當前的事件具體是什麼的前提下，直接調用綁定到事件上的command 接口方法。例2驗證僱員信息合法性的實現。在增長每一個僱員信息到數據庫以前都有對其全部信息的合法性進行驗證。僱傭方式不一樣的僱員，其相關信息也是不同的。如按小時工做的員工須要有相關的時間信息，而按業績支付的也須要有相應的時間和數量，按月支付的員工則沒有額外的信息。但在作增長一個僱員信息的事務時，能隔離掉對具體信息的依賴，能夠減小這個事務代碼實現的複雜性。《敏捷》在網上有電子書，各位能夠對照着看看具體的架構實現。

針對《敏捷》中僱員事務的實現，來講明一種可能比較常見的方法，首先聲明，這裏說明的方法，從必定意義上講，是沒有考慮面向對象這些設計的，而是咱們常常隨手拈來寫代碼湊出來的習慣，寫在這裏，是想提醒本身，之後碰到這樣的場景，應該考慮一下設計模式。看到這個需求，咱們的第一印象，應該是給僱員分類：

public enum EmployeeType {

HOUR(1),

MONTH(2),

COMMISSION(3);

private EmployeeType(int type){

this.type = type;

}

private int type;

public int getValue(){

return this.type;

}

}

而後在實現AddEmployeeTransaction時，判斷加入的Employee的type. 跟Bob的實現相比，咱們少了什麼，又多了什麼？個人答案確定不是惟一的，不只是對這個需求的實現，還有前面這個問題。我來講一下本身的見解：

1.過程性的思惟定勢，使得AddEmployeeTransaction須要瞭解所有的可能狀況，在種類繁多的狀況下，可能會出現一個極其龐大，充滿了if－else的大方法；

2.由於第一點，咱們確定建立了一個極其簡單POJO 對象，不少人都會直接命名成VO（ValueObject）。

因而，各類所謂的smell就會出現。那麼這個時候，咱們可能經過重構來抽取出一些小方法，來格式化一個龐大的方法。如此之多的方法是否在說明一個問題，一些行爲是否能夠造成抽象。由於咱們知道if－else比較多的狀況下，要考慮command，strategy之類的設計模式，爲何？由於這些模式都是面向行爲的，而咱們就是在針對行爲進行重構。

想到這裏，忽然對《重構》這本人人喜好的書有點可惜，要是它裏面能關聯上設計模式方面的內容，可能會更具震撼力，由於行動加上理論依據更有說服力，也能夠在老是學重構方法方式的時候能思考一下，什麼樣的重構推出來什麼樣的模式。

以上是個人我的看法，是作了7，8年的一個對本身編碼方式的總結，後面的一些設計模式，也會帶上我的色彩的自我剖析。

那麼爲何要講command模式，固然接這個機會都學一遍，但在《設計模式》中關於Command模式的應用部分，其中的一種方式就是採用callback的方式來提供action perform，從而在時間上和引用上都隔離request和調用者。spring裏面在闡述IoC的時候，尤爲是關於jdbc的封裝，它將具體業務相關的動做放到一個callback對象中，而JdbcTemplate能夠在絕不關心具體業務動做的情況下，進行調用。

但願這個關聯，有助於加深對spring設計的理解。

 在part2，再討論其餘幾個相關的設計模式，或許多少都會提一下。《設計模式》，《敏捷》，《Expert》這三本書再次捧在手上仍是引人入勝，只是如今不會再像之前那麼急躁，那麼不顧實際場景的使用。因爲spring這個框架自己就是個集大成的模板，這是一個極好的機會能切實看到大師級的架構思路，因此後面看狀況，若有必要，就一會兒把設計模式都過一遍。