談?wù)劇澳Ｊ剿枷搿迸c框架的關(guān)系

良言有益，現(xiàn)在各種框架越來(lái)越多;模式使用機(jī)會(huì)性似乎減少了，那么是不是意味著我們就不必掌握模式了呢?其實(shí)，學(xué)習(xí)模式實(shí)際為了培養(yǎng)模式思維，模式思維有助于了解和使用框架。

現(xiàn)在各種框架越來(lái)越多;模式使用機(jī)會(huì)性似乎減少了，那么是不是意味著我們就不必掌握模式了呢?其實(shí)，學(xué)習(xí)模式實(shí)際為了培養(yǎng)模式思維，模式思維有助于了解和使用框架。

例如如何我們?cè)谑褂帽憩F(xiàn)層哪個(gè)框架，都是MVC模式實(shí)現(xiàn)，那么進(jìn)行編程步驟時(shí)，我們腦海里就浮現(xiàn)一個(gè)步驟V/C/M以及C和V的轉(zhuǎn)發(fā)關(guān)系，進(jìn)而感覺(jué)struts-config.xml配置就不是多余或復(fù)雜，而是必須的。

現(xiàn)在有人覺(jué)得好像Java世界框架特別多，異常復(fù)雜，其實(shí)這可能是他從封閉世界走向開(kāi)放自由世界產(chǎn)生的錯(cuò)覺(jué)，當(dāng)你具備模式思維時(shí)，實(shí)際你就具備了挑選各種 各樣框架的能力，打個(gè)比喻：以選擇轎車(chē)為例子，過(guò)去，只有一種“紅旗”轎車(chē)供選擇，你就只有接受這個(gè)轎車(chē);但是現(xiàn)在轎車(chē)多了，選擇多了，你就必須了解轎車(chē) 的通用概念，進(jìn)而你就可以在各種轎車(chē)之間選擇和衡量，了解轎車(chē)的通用概念這個(gè)過(guò)程就如同我們學(xué)習(xí)模式，具備通用編程的模式思維，有了模式思維，就會(huì)發(fā)現(xiàn)有 這么多選擇產(chǎn)品，不再嫌復(fù)雜，而是變得興奮了;所以，沒(méi)有復(fù)雜的東西，只有是否原意學(xué)習(xí)的頭腦;PC電腦對(duì)于一些人很復(fù)雜，可是對(duì)于我們會(huì)復(fù)雜嗎?不會(huì)， 因?yàn)槲覀円呀?jīng)掌握通用電腦的模型、模式。

所以，有人覺(jué)得Java軟件很多配置復(fù)雜，甚至產(chǎn)生配置恐懼癥，那是因?yàn)樗麤](méi)有模式思維，在模式思維指導(dǎo)下的編程工作，就象在寫(xiě)一篇生動(dòng)的小說(shuō)一樣，你腦 海展現(xiàn)的生動(dòng)模式實(shí)現(xiàn)步驟，而無(wú)論代碼或配置都是實(shí)現(xiàn)你模式思維的文字工具，模式思維考慮到哪里，就想起什么配置，配置對(duì)具備模式思維的你來(lái)說(shuō)是很自然的 表達(dá)。

在模式思維下的Java編程，編碼階段code completion可能花費(fèi)2/3時(shí)間，但是調(diào)試測(cè)試時(shí)間只需要1/3甚至不到，大多數(shù)情況下是一步到位的調(diào)試成功;這比以前1/3編程時(shí)間，2/3調(diào) 試時(shí)間要高效多，關(guān)鍵是：你無(wú)論花費(fèi)多少時(shí)間在調(diào)試上，實(shí)際上是在做一個(gè)修修補(bǔ)補(bǔ)的工作，是在做維修工，頭疼醫(yī)頭，永遠(yuǎn)是機(jī)修工，無(wú)法成為設(shè)計(jì)師。

下面從模式思維角度談?wù)剮讉€(gè)認(rèn)識(shí)誤區(qū)，僅僅參考討論：

游戲軟件比企業(yè)軟件復(fù)雜?

為什么說(shuō)企業(yè)軟件時(shí)復(fù)雜的?因?yàn)槠髽I(yè)軟件是為應(yīng)付需求而變，與游戲軟件等軟件相比，雖然一個(gè)游戲軟件在代碼數(shù)量級(jí)別上比企業(yè)軟件復(fù)雜，但是游戲軟件不必考 慮跟隨游戲用戶需求變化，是游戲用戶服務(wù)游戲設(shè)計(jì)規(guī)則;但是企業(yè)軟件和其用戶則相反，企業(yè)軟件必須服從用戶的變化，打個(gè)不是很確切的比喻：企業(yè)軟件則類似 市場(chǎng)經(jīng)濟(jì)中的市場(chǎng)人員，需要“看客戶臉色”行事。而游戲軟件則相反，類似以前朝南坐的政府人員;

因此，企業(yè)軟件在動(dòng)態(tài)概念上是隨時(shí)間變化而變化，是由生命的，因?yàn)橛?jì)劃趕不上變化，所以企業(yè)軟件制作時(shí)總是使用模式為將來(lái)變化預(yù)留余地，這種面向未來(lái)變化 考慮方式無(wú)疑是最復(fù)雜的思維，就象股票變化將這種未來(lái)變化的殘酷推向極致，我們都想計(jì)劃未來(lái)，但是總是計(jì)劃不了未來(lái)，這就是企業(yè)軟件的復(fù)雜所在。

Class.forName神秘嗎?

有人覺(jué)得Class.forName很神秘，神秘不在于本身，就是打開(kāi)其編碼研究到二進(jìn)制也不能達(dá)到目的，它的神秘之處是因?yàn)閼?yīng)用在一個(gè)恰當(dāng)之處，就象一 塊普通布沒(méi)什么，但是如果從后面變出花了，你覺(jué)得這塊布神奇了，Class.forName神奇之處在于其隱藏了對(duì)象創(chuàng)建，也一種是工廠模式實(shí)現(xiàn)。

同樣，對(duì)于Collection，本來(lái)就是那幾個(gè)種類List和Map，但是發(fā)現(xiàn)使用起來(lái)神奇得很，有人甚至研究過(guò)Collection的二進(jìn)制，這和研 究魔術(shù)師中一塊普通布沒(méi)有什么區(qū)別。Collection用于容器，作為對(duì)象集合;以及和單例結(jié)合實(shí)現(xiàn)緩存等，可以實(shí)現(xiàn)多種模式。

僅會(huì)算法就做企業(yè)軟件嗎?

在實(shí)踐中，通常表示一個(gè)樹(shù)形關(guān)系通過(guò)編碼實(shí)現(xiàn)，例如1122334455表示是代號(hào)為11類別下代號(hào)為22類別下的代號(hào)為33類別下的....然后，在軟件各處通過(guò)分析這個(gè)類別編碼獲得樹(shù)形關(guān)系，這種將將具體數(shù)據(jù)和業(yè)務(wù)耦合在一起做法是受到抨擊的。

那么如果我們要對(duì)樹(shù)形關(guān)系的數(shù)據(jù)進(jìn)行訪問(wèn)如何實(shí)現(xiàn)呢?首先我們將樹(shù)形關(guān)系的訪問(wèn)分為兩個(gè)部分：樹(shù)形關(guān)系+功能實(shí)現(xiàn)。我們已經(jīng)知曉樹(shù)形結(jié)構(gòu)的遍歷，但是僅僅 知道樹(shù)形結(jié)構(gòu)遍歷還是不夠的，我們還需要模式來(lái)解決樹(shù)形關(guān)系訪問(wèn)這個(gè)通用問(wèn)題，使用Composite模式可以方便客戶端對(duì)樹(shù)形結(jié)構(gòu)訪問(wèn)，使得客戶端不至 于因?yàn)闃?shù)形結(jié)構(gòu)變化而變化不定;而訪問(wèn)者模式則不會(huì)總可能新增的新訪問(wèn)功能，導(dǎo)致樹(shù)形結(jié)構(gòu)中對(duì)象代碼變化不定。

這兩種模式協(xié)同發(fā)力，可以綜合解決樹(shù)形結(jié)構(gòu)中對(duì)象群的訪問(wèn)。

http://www.jdon.com/jive/thread.jsp?forum=91&thread=23857

GoF模式打開(kāi)的新境界

沒(méi)有知曉GoF模式之前，我們總是以為編碼就是寫(xiě)一些代碼，然后運(yùn)行，復(fù)雜嗎?如果我們來(lái)分析一下GoF模式三個(gè)類型，你會(huì)發(fā)現(xiàn)平時(shí)熟視無(wú)睹的代碼中隱藏如此多考慮方面。

GOF模式三種類型：結(jié)構(gòu)型模式、創(chuàng)建型模式和行為型模式其實(shí)函括了OO編碼的三個(gè)方面：靜態(tài)類關(guān)系、類創(chuàng)建成為運(yùn)行時(shí)對(duì)象實(shí)例;運(yùn)行時(shí)的對(duì)象運(yùn)行行為，也就是說(shuō)，我們?cè)诰幋a階段不但考慮現(xiàn)階段各個(gè)類之間靜態(tài)解耦關(guān)系，而且還要考慮這些代碼激活后，運(yùn)行時(shí)的情況。

而以往過(guò)程化編程中，編碼狀況=運(yùn)行狀況，如何先后編碼，這些編碼運(yùn)行時(shí)就按照這些先后編碼順序執(zhí)行，兩者是統(tǒng)一的，不可能出現(xiàn)運(yùn)行時(shí)可能和編碼時(shí)預(yù)想不 一樣，更何況需要我們還要在進(jìn)行類編碼時(shí)，考慮這些類運(yùn)行時(shí)是如何實(shí)現(xiàn)的，有如何對(duì)這些類運(yùn)行時(shí)的關(guān)系進(jìn)行解耦和分離呢?所以，我們“天生”就無(wú)法理解設(shè) 計(jì)模式，因?yàn)槲覀儚膩?lái)就認(rèn)為軟件就是實(shí)現(xiàn)功能，哪里還會(huì)考慮到實(shí)現(xiàn)同樣功能會(huì)涉及各種考量了呢?

如果說(shuō)設(shè)計(jì)模式是程序員的圣經(jīng)，那么不掌握設(shè)計(jì)模式可能就是異教徒，從此教徒和異教徒兩者之間就缺乏溝通對(duì)話平臺(tái)，就象雞對(duì)鴨講話了。

非模式思維的懲罰

面向?qū)ο筌浖w系是和面向過(guò)程體系格格不入的，面向?qū)ο蟮母鞣N技術(shù)如單元測(cè)試　性能緩存等等都是OO體系，如果我們沒(méi)有具備模式思維來(lái)編程，由此而誕生的 軟件架構(gòu)必然失敗，失敗在哪里?通過(guò)性能懲罰你。最近碰到一個(gè)臺(tái)灣的鋼鐵架構(gòu)，它雖然包含一個(gè)簡(jiǎn)單的MVC框架，但是其Controller實(shí)際又是 Service，該框架配置將下面幾個(gè)元素耦合在一起：頁(yè)面流程;控制類;Dao與VO，這實(shí)際是將表現(xiàn)層和持久層直接結(jié)合一起，這樣的框架迫使程序員沒(méi) 有空間做中間領(lǐng)域模型層和服務(wù)層，進(jìn)而整個(gè)體系變成一個(gè)兩層耦合結(jié)構(gòu)，這和傳統(tǒng)的C/S沒(méi)有區(qū)別，在Java中使用傳統(tǒng)概念編程：如面向過(guò)程、面向數(shù)據(jù)表 以及兩層耦合導(dǎo)致結(jié)果是性能緩慢，很多大型項(xiàng)目就是這樣最后是毀在性能上，服務(wù)器需要經(jīng)常啟動(dòng)，一旦并發(fā)用戶就很慢，服務(wù)器經(jīng)常死機(jī)。

有人可能奇怪：非模式思維屬于設(shè)計(jì)問(wèn)題，怎么會(huì)對(duì)性能影響，這是將設(shè)計(jì)和性能對(duì)立起來(lái)，性能也是一種設(shè)計(jì)，池模式以及緩存也是屬于模式啊，但是緩存的高效 率應(yīng)用是建立良好的對(duì)象設(shè)計(jì)基礎(chǔ)上，或者說(shuō)是良好的領(lǐng)域建模上，否則就是使用緩存，也會(huì)導(dǎo)致粒度或動(dòng)態(tài)機(jī)制不準(zhǔn)確，無(wú)法發(fā)揮緩存效率，甚至無(wú)法使用緩存。