這段時間接了別人的一個小項目,這個項目不大,需求文檔也就10幾頁,並且裏面主要是流程圖,具體業務邏輯很是少。一個大的方法幾乎能夠涵蓋全部的東西,但這哥們就是要套用設計模式,一上來就是命令模式,說是命令模式,其實就是命名叫command,在這個所謂的「Command」模式裏面摻雜了proxy模式,filter模式,還有什麼工廠模式。真叫一個「坑爹」啊。原本就是2-3個類能解決的問題,一會兒就出來二三十個,依賴關係還比較亂。能有關係的地方都用上了模式。html
寫這個文章的主要目的是想分享一下本身的一些見解,上面這小段算是個引子。spring
在剛學設計模式的時候,也喜歡處處宣揚設計模式的優勢,並喜歡在代碼裏面套用,當初就特別注意《Design Patterns》裏面在每一個模式開始的地方寫的一些前置條件。也就是關於應用場景的說明。因而出現了一種狀況:手裏拿着錘子,發現什麼都像釘子。明明不符合場景的地方,頓時以爲就特別適合這種設計模式,到最後把本身也攪和在一片混亂依賴之中。本身有過這樣的痛苦經歷,再次碰到印象特別深入。因此如今就特別特別想就設計模式這個「好東西」再剖析一番。設計模式
咱們常常據說「xx是把雙刃劍」,設計模式也符合這種狀況,尤爲是在咱們想應用的「時候」,而這個「時候」尤爲不能是在設計的創建第一印象的時候。在這篇文章裏面,我提起過,要是《重構》能再擴展一些,將重構的方法跟設計模式結合起來,會更加有價值。爲何這樣說呢?由於,一是咱們要重構,是由於如今的代碼不利於擴展,或不便於維護,還有一點就在於咱們如何驗證重構的準確性。按照《重構》的方法論進行操做以後,咱們的代碼真的架構結構上就變得很嚴謹了麼?仍是在那篇文章裏面我提到過,咱們可能會抽取出不少的類,對象,方法等等元素,可是如何合理的對他們進行組合?僅僅是換個包依賴或者調用就能夠麼?實際上,在《重構》裏面也是屢次提起,英國根據業務須要進行劃分,那這個時候就應該考慮一下設計模式。設計模式的出發點就是擴展性,穩定性和鬆耦合,這正是咱們重構要達到的目的,固然這個時候咱們依然要提醒本身,不要客氣套用設計模式。與此同時,咱們還要聯想一下《design patterns》裏面按照建立性,結構性,行爲三個方面歸類了設計模式,那麼在進行重構的時候,咱們能夠結合那三個方面考慮是否有模式適用當前場景。架構
通過《重構》的代碼,首先是基於一種場景的,而重構中每一步操做還須要準備單元測試,結合TDD,咱們能夠很快的驗證咱們的設計是否正常,是否違背咱們的易於維護,易於擴展,高內聚,低耦合的目的。框架
由於還要寫spring框架的分析, 這個帖子想專一與設計模式方面,能再好好總結總結,未完待續。單元測試