談談“模式思維”

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

例如如何我們在使用表現層哪個框架，都是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

相關文章