- 重複使用設計過的軟體元件
- 快速解決問題
- 促進良好溝通
但，真的是這樣嗎？真的不用重新發明輪子嗎？有沒有想過設計模式真的有解決問題嗎？有沒有想過設計模式帶來的問題，其實多過他所解決的問題？老實說，
第一、設計模式最大的問題在於本身太過複雜。
事實上，我十分懷疑究竟有多少人看的懂物件導向設計模式這本書，我寧可回歸最直覺、簡單的解法來解決問題。
第二、要是你不斷用同一個設計模式解決重複出現的問題，這代表什麼？這代表這個語言本身出了問題，你看看Façade。
Façade當初是為了對付EJB過於龐大臃腫的架構而出現的，當然啦，這讓整個架構稍微簡單了一點點，但到頭來還不是一個功能一支Façade，深入去看看程式，你覺得這有讓SQL語法變少嗎？並沒有吧。
別跟我說SQL是歸DAO管的，DAO是另一個十分嚴重的問題，那裡頭糊成一團，是DAO這團麵粉桿出了一堆義大利麪。
但那是沒辦法的，當年膨風過度的ORM，事實上窒礙難行，無論實務面或理論面，幾乎交錯混亂而演變成一場電腦科學界的越戰了。
所以這些設計模式解決了什麼問題？頂多創造出好幾個令人摸不著頭緒的新名詞吧。
軟體設計發展的太過複雜、太過疊樑架屋之後，於是就像電影侏羅紀公園講的，生命會找到出路(Life will find a way)。
於是開始回歸原點，開始反思如何運用POJO，如何運用Hibernate, Spring之類的方式來解決問題，可惜的是，無論採用哪種方式，背後還是堆砌過多的技術性與複雜性。
Groovy是一個好的開始，加油吧。
但我相信那條出路是Ruby On Rails。
