程式開發模式思維

現在各種框架越來越多；模式使用機會性似乎減少了，那麼是不是意味著我們就不必掌握模式了呢？其實，學習模式實際為了培養模式思維，模式思維有助於瞭解和使用框架。

例如如何我們在使用表現層哪個框架，都是MVC模式實現，那麼進行編程步驟時，我們腦海?就浮現一個步驟V/C/M以及C和V的轉發關係，進而感覺struts-config.xml配置就不是多餘或複雜，而是必須的。

現在有人覺得好像Java世界框架特別多，異常複雜，其實這可能是他從封閉世界走向開放自由世界產生的錯覺，當你具備模式思維時，實際你就具備了挑選各種各樣框架的能力，打個比喻：以選擇轎車為例子，過去，只有一種“紅旗”轎車供選擇，你就只有接受這個轎車；但是現在轎車多了，選擇多了，你就必須瞭解轎車的通用概念，進而你就可以在各種轎車之間選擇和衡量，瞭解轎車的通用概念這個過程就如同我們學習模式，具備通用編程的模式思維，有了模式思維，就會發現有這麼多選擇產品，不再嫌複雜，而是變得興奮了；所以，沒有複雜的東西，只有是否原意學習的頭腦；PC電腦對於一些人很複雜，可是對於我們會複雜嗎？不會，因為我們已經掌握通用電腦的模型、模式。

所以，有人覺得Java軟體很多配置複雜，甚至產生配置恐懼症，那是因為他沒有模式思維，在模式思維指導下的編程工作，就象在寫一篇生動的小說一樣，你腦海展現的生動模式實現步驟，而無論代碼或配置都是實現你模式思維的文字工具，模式思維考慮到哪里，就想起什麼配置，配置對具備模式思維的你來說是很自然的表達。

在模式思維下的Java編程，編碼階段code completion可能花費2/3時間，但是調試測試時間只需要1/3甚至不到，大多數情況下是一步到位的調試成功；這比以前1/3編程時間，2/3調試時間要高效多，關鍵是：你無論花費多少時間在調試上，實際上是在做一個修修補補的工作，是在做維修工，頭疼醫頭，永遠是機修工，無法成為設計師。

下面從模式思維角度談談幾個認識誤區，僅僅參考討論：

遊戲軟體比企業軟體複雜？
為什麼說企業軟體時複雜的？因為企業軟體是為應付需求而變，與遊戲軟體等軟體相比，雖然一個遊戲軟體在代碼數量級別上比企業軟體複雜，但是遊戲軟體不必考慮跟隨遊戲用戶需求變化，是遊戲用戶服務遊戲設計規則；但是企業軟體和其用戶則相反，企業軟體必須服從用戶的變化，打個不是很確切的比喻：企業軟體則類似市場經濟中的市場人員，需要“看客戶臉色”行事。而遊戲軟體則相反，類似以前朝南坐的政府人員；

因此，企業軟體在動態概念上是隨時間變化而變化，是由生命的，因為計畫趕不上變化，所以企業軟體製作時總是使用模式為將來變化預留餘地，這種面向未來變化考慮方式無疑是最複雜的思維，就象股票變化將這種未來變化的殘酷推向極致，我們都想計畫未來，但是總是計畫不了未來，這就是企業軟體的複雜所在。

Class.forName神秘嗎？
有人覺得Class.forName很神秘，神秘不在於本身，就是打開其編碼研究到二進位也不能達到目的，它的神秘之處是因為應用在一個恰當之處，就象一塊普通布沒什麼，但是如果從後面變出花了，你覺得這塊布神奇了，Class.forName神奇之處在於其隱藏了物件創建，也一種是工廠模式實現。

同樣，對於Collection，本來就是那幾個種類List和Map，但是發現使用起來神奇得很，有人甚至研究過Collection的二進位，這和研究魔術師中一塊普通布沒有什麼區別。Collection用於容器，作為物件集合；以及和單例結合實現緩存等，可以實現多種模式。

僅會演算法就做企業軟體嗎？
在實踐中，通常表示一個樹形關係通過編碼實現，例如1122334455表示是代號為11類別下代號為22類別下的代號為33類別下的....然後，在軟體各處通過分析這個類別編碼獲得樹形關係，這種將將具體資料和業務耦合在一起做法是受到抨擊的。

那麼如果我們要對樹形關係的資料進行訪問如何實現呢？首先我們將樹形關係的訪問分為兩個部分：樹形關係＋功能實現。我們已經知曉樹形結構的遍曆，但是僅僅知道樹形結構遍曆還是不夠的，我們還需要模式來解決樹形關係訪問這個通用問題，使用Composite模式可以方便用戶端對樹形結構訪問，使得用戶端不至於因為樹形結構變化而變化不定；而訪問者模式則不會總可能新增的新訪問功能，導致樹形結構中物件代碼變化不定。
這兩種模式協同發力，可以綜合解決樹形結構中物件群的訪問。
http://www.jdon.com/jive/thread.jsp?forum=91&thread=23857

GoF模式打開的新境界
沒有知曉GoF模式之前，我們總是以為編碼就是寫一些代碼，然後運行，複雜嗎？如果我們來分析一下GoF模式三個類型，你會發現平時熟視無睹的代碼中隱藏如此多考慮方面。

GOF模式三種類型：結構型模式、創建型模式和行為型模式其實函括了OO編碼的三個方面：靜態類關係、類創建成為運行時物件實例；運行時的物件運行行為，也就是說，我們在編碼階段不但考慮現階段各個類之間靜態解耦關係，而且還要考慮這些代碼啟動後，運行時的情況。

而以往過程化編程中，編碼狀況=運行狀況，如何先後編碼，這些編碼運行時就按照這些先後編碼順序執行，兩者是統一的，不可能出現運行時可能和編碼時預想不一樣，更何況需要我們還要在進行類編碼時，考慮這些類運行時是如何實現的，有如何對這些類運行時的關係進行解耦和分離呢？所以，我們“天生”就無法理解設計模式，因為我們從來就認為軟體就是實現功能，哪里還會考慮到實現同樣功能會涉及各種考量了呢？

如果說設計模式是程式師的聖經，那麼不掌握設計模式可能就是異教徒，從此教徒和異教徒兩者之間就缺乏溝通對話平臺，就象雞對鴨講話了。

非模式思維的懲罰
面向物件軟體體系是和面向過程體系格格不入的，面向物件的各種技術如單元測試　性能緩存等等都是OO體系，如果我們沒有具備模式思維來編程，由此而誕生的軟體架構必然失敗，失敗在哪里？通過性能懲罰你。最近碰到一個臺灣的鋼鐵架構，它雖然包含一個簡單的MVC框架，但是其Controller實際又是Service，該框架配置將下面幾個元素耦合在一起：頁面流程；控制類；Dao與VO，這實際是將表現層和持久層直接結合一起，這樣的框架迫使程式師沒有空間做中間領域模型層和服務層，進而整個體系變成一個兩層耦合結構，這和傳統的C/S沒有區別，在Java中使用傳統概念編程：如面向過程、面向資料表以及兩層耦合導致結果是性能緩慢，很多大型專案就是這樣最後是毀在性能上，伺服器需要經常啟動，一旦併發用戶就很慢，伺服器經常死機。

有人可能奇怪：非模式思維屬於設計問題，怎麼會對性能影響，這是將設計和性能對立起來，性能也是一種設計，池模式以及緩存也是屬於模式啊，但是緩存的高效率應用是建立良好的物件設計基礎上，或者說是良好的領域建模上，否則就是使用緩存，也會導致粒度或動態機制不準確，無法發揮緩存效率，甚至無法使用緩存。

原文出處http://www.jdon.com/artichect/state.htm