神話設計模式 －－開端

這段時間接了別人的一個小項目，這個項目不大，需求文檔也就10幾頁，並且裏面主要是流程圖，具體業務邏輯很是少。一個大的方法幾乎能夠涵蓋全部的東西，但這哥們就是要套用設計模式，一上來就是命令模式，說是命令模式，其實就是命名叫command，在這個所謂的「Command」模式裏面摻雜了proxy模式，filter模式，還有什麼工廠模式。真叫一個「坑爹」啊。原本就是2－3個類能解決的問題，一會兒就出來二三十個，依賴關係還比較亂。能有關係的地方都用上了模式。

寫這個文章的主要目的是想分享一下本身的一些見解，上面這小段算是個引子。

在剛學設計模式的時候，也喜歡處處宣揚設計模式的優勢，並喜歡在代碼裏面套用，當初就特別注意《Design Patterns》裏面在每一個模式開始的地方寫的一些前置條件。也就是關於應用場景的說明。因而出現了一種狀況：手裏拿着錘子，發現什麼都像釘子。明明不符合場景的地方，頓時以爲就特別適合這種設計模式，到最後把本身也攪和在一片混亂依賴之中。本身有過這樣的痛苦經歷，再次碰到印象特別深入。因此如今就特別特別想就設計模式這個「好東西」再剖析一番。

咱們常常據說「xx是把雙刃劍」，設計模式也符合這種狀況，尤爲是在咱們想應用的「時候」，而這個「時候」尤爲不能是在設計的創建第一印象的時候。在這篇文章裏面，我提起過，要是《重構》能再擴展一些，將重構的方法跟設計模式結合起來，會更加有價值。爲何這樣說呢？由於，一是咱們要重構，是由於如今的代碼不利於擴展，或不便於維護，還有一點就在於咱們如何驗證重構的準確性。按照《重構》的方法論進行操做以後，咱們的代碼真的架構結構上就變得很嚴謹了麼？仍是在那篇文章裏面我提到過，咱們可能會抽取出不少的類，對象，方法等等元素，可是如何合理的對他們進行組合？僅僅是換個包依賴或者調用就能夠麼？實際上，在《重構》裏面也是屢次提起，英國根據業務須要進行劃分，那這個時候就應該考慮一下設計模式。設計模式的出發點就是擴展性，穩定性和鬆耦合，這正是咱們重構要達到的目的，固然這個時候咱們依然要提醒本身，不要客氣套用設計模式。與此同時，咱們還要聯想一下《design patterns》裏面按照建立性，結構性，行爲三個方面歸類了設計模式，那麼在進行重構的時候，咱們能夠結合那三個方面考慮是否有模式適用當前場景。

通過《重構》的代碼，首先是基於一種場景的，而重構中每一步操做還須要準備單元測試，結合TDD，咱們能夠很快的驗證咱們的設計是否正常，是否違背咱們的易於維護，易於擴展，高內聚，低耦合的目的。

 

由於還要寫spring框架的分析， 這個帖子想專一與設計模式方面，能再好好總結總結，未完待續。