例如如何我們在使用表現層哪個框架，都是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模式可以方便客戶端對樹形結構訪問，使得客戶端不至於因為樹形結構變化而變化不定；而訪問者模式則不會總可能新增的新訪問功能，導致樹形結構中對象代碼變化不定。
這兩種模式協同發力，可以綜合解決樹形結構中對象群的訪問。
GoF模式打開的新境界
沒有知曉GoF模式之前，我們總是以為編碼就是寫一些代碼，然後運行，復雜嗎？如果我們來分析一下GoF模式三個類型，你會發現平時熟視無睹的代碼中隱藏如此多考慮方面。
GOF模式三種類型：結構型模式、創建型模式和行為型模式其實函括了OO編碼的三個方面：靜態類關系、類創建成為運行時對象實例；運行時的對象運行行為，也就是說，我們在編碼階段不但考慮現階段各個類之間靜態解耦關系，而且還要考慮這些代碼激活後，運行時的情況。
而以往過程化編程中，編碼狀況=運行狀況，如何先後編碼，這些編碼運行時就按照這些先後編碼順序執行，兩者是統一的，不可能出現運行時可能和編碼時預想不一樣，更何況需要我們還要在進行類編碼時，考慮這些類運行時是如何實現的，有如何對這些類運行時的關系進行解耦和分離呢？所以，我們“天生”就無法理解設計模式，因為我們從來就認為軟件就是實現功能，哪裡還會考慮到實現同樣功能會涉及各種考量了呢？
如果說設計模式是程序員的聖經，那麼不掌握設計模式可能就是異教徒，從此教徒和異教徒兩者之間就缺乏溝通對話平台，就象雞對鴨講話了。
非模式思維的懲罰
面向對象軟件體系是和面向過程體系格格不入的，面向對象的各種技術如單元測試 性能緩存等等都是OO體系，如果我們沒有具備模式思維來編程，由此而誕生的軟件架構必然失敗，失敗在哪裡？通過性能懲罰你。最近碰到一個台灣的鋼鐵架構，它雖然包含一個簡單的MVC框架，但是其Controller實際又是Service，該框架配置將下面幾個元素耦合在一起：頁面流程；控制類；Dao與VO，這實際是將表現層和持久層直接結合一起，這樣的框架迫使程序員沒有空間做中間領域模型層和服務層，進而整個體系變成一個兩層耦合結構，這和傳統的C/S沒有區別，在Java中使用傳統概念編程：如面向過程、面向數據表以及兩層耦合導致結果是性能緩慢，很多大型項目就是這樣最後是毀在性能上，服務器需要經常啟動，一旦並發用戶就很慢，服務器經常死機。
有人可能奇怪：非模式思維屬於設計問題，怎麼會對性能影響，這是將設計和性能對立起來，性能也是一種設計，池模式以及緩存也是屬於模式啊，但是緩存的高效率應用是建立良好的對象設計基礎上，或者說是良好的領域建模上，否則就是使用緩存，也會導致粒度或動態機制不准確，無法發揮緩存效率，甚至無法使用緩存。
