1. 我說下我對設計模式的理解：任何一樣事物都是因為有需求的驅動才誕生的，所以設計模式也不例外，我們平時在編寫代碼的時候，隨著時間的深入，發現很多代碼很難維護，可擴展性級差，以及代碼的效率也比較低，這個時候你肯定會想辦法讓代碼變的優美又能解決你項目中的問題，所以在面向對象語言里，你肯定會去發現很多可以重用的公用的方法，比如：接口的存在，你自然就想到了，讓你定義的方法與你的實現分開，也可以很方便把不同的類與接口匹配起來，形成了一個公用的接口，你會發現這樣做，好處會是非常多的，解決了你平時想把代碼的申明與邏輯實現的分開。
2. 這個時候，你發現了，本身面向對象的語言里，已經暗藏了很多好處，你肯定會仔細去分析面向對象這個語言，認真去挖掘里面更多的奧秘，最后，你發現了，原來你可以把面向對象的特性提取成一個公用的實現案例，這些案例里能幫助你解決你平時編寫代碼的困擾，而這樣一群人，就是所謂gof的成員，他們從平時設計建筑方面找到了靈感，建筑的設計也可以公用化以及重用化，所以他們也提取了相關的軟件設計方面的公用案例，也就有了下面的相關的所謂23種設計模式，而里面這么多模式，你也可以把他們歸類起來，最后發現就幾類模式：創建，結構，行為等模式類別，而這些現成的方案，也可以在實際應用中充分發揮作用，隨著大家的使用以及理解，發現其實這些所謂的模式里，你的確可以讓你的代碼變的更加優美與簡練。
3. 我比較喜歡把代碼變的更加優美與簡練，優美的代碼就是一看就懂，結構很清晰，而簡歷就是一目了然，又可以解決你的問題，就是代碼又少效率又高，所以平時要養成寫java doc的習慣，這樣的代碼才為清晰，所以才會更加優美。
4. 這些就是我對設計模式的理解，所以這么好的寶貝，我們不去深入的了解，的確可惜了，這就叫站到巨人的肩膀上.....