記得2004年剛接觸設計模式，買了經典的<<設計模式>>一書，細細地閱讀，然后在開發中模仿。一兩年時間過去，對23種設計模式弄得還算比較熟悉，也在軟件設計中能用則用，比如Singleton, template method, proxy, facade等等。但總感覺用的不爽，當時也說不出原因；就是感覺在使用的過程中，是一種為了使用設計模式而使用上他們，有時候是生搬硬套。總之，自己當時是搞不清楚為什么要使用設計模式，停留在別人說它牛，我就學著用而不落人之后。
我不是一個天質聰穎的人，對軟件設計的理解，基本上無法評自己能力單獨領悟出來。只有常常督促自己多買國內外軟件專家寫的好書，來學習他們在這些方面的發現和總結。靠后天學習來彌補先天不足，也是沒有辦法中的辦法。
終于在2007年看到了<<java與模式>>，書中對設計模式的討論，并沒有特別吸引我的地方，不過是用java語言來詳細講解23種模式而已，最多增加一些變體。深深吸引我的是"第二部分 面向對象的設計原則"，這一部分雖然篇幅不多，但清晰地說明了我們為什么要用設計模式，使用設計模式是來解決什么問題的，使用之后我們要達到什么效果。軟件的生命周期讓我們認識到，面向對象的設計要解決的核心問題是可維護性和可復用性，特別是可維護性，一個好軟件的維護成本遠遠大于初期開發成本。
一個軟件設計的可維護性很差，原因在于：過于僵硬、過于脆弱、復用率低、黏度過高。相反，一個好的系統設計應該是可擴展的、靈活的、可插入的。在軟件發達國家如美國，一些軟件界的高手，在20世紀80~90年代，就陸續提出一些設計原則，這些設計原則是在提高一個系統的可維護性的同時，提高系統的可復用性的指導原則：
1、開閉原則：軟件架構應該是對擴展開發，對修改關閉
2、Liskov替換原則：任何基類可以出現的地方，子類一定可以出現
3、依賴倒轉原則：要依賴于抽象，不要依賴于實現
4、接口隔離原則：應當為客戶提供盡可能小的接口，而不是提供大的接口。
5、組合、聚合復用原則：要盡量使用組合、聚合，而不是繼承關系以達到復用的目的。
6、Demeter法則：一個軟件實體應該與盡可能少的其他實體發生互相作用。
可以說，<<java與模式>>里很好的解決了我心中兩三年來的不快，讓我真正理解了為什么要使用設計模式。軟件開發、設計原則與設計模式的關系，我不恰當的比喻為戰爭、戰略與戰術的關系；要取得戰爭的全面勝利，你首先要在戰略上把握好，然后才是戰術上指揮好；同樣，要開發出好的軟件，我們首先要遵循一定的設計原則，為了達到我們的目的，在開發中我們就恰當的使用相應的設計模式。
<<java與模式>>寫的好，而且是中國人寫的，但它缺少了一個方面的描述：我們怎樣在實際的設計開發中做到這些呢？是不是一開始就要遵循這些設計原則，就要使用設計模式？還是有一個什么樣的過程？
終于今年初看到了英文版<<敏捷軟件開發：原則、模式與實踐>>，國外這些大牛就是大牛，在這方面就是理解深刻，實踐經驗豐富。作者的觀點很有點唯物辨證法，就是軟件設計開始時，我們如果沒有看出抽象的必要，可以先實現一個簡單的，當第一次被需求觸發而顯現出抽象的必要時，我們這時機會就來了，需要很快提取抽象接口，遵循以上設計原則。當然，作者還有很多其它好的思想，這里不一一列舉。
認識和理解都需要一個過程，沒有理論，我們這些智商一般的人是很難僅僅在項目開發中盡快提高的；同樣，光看書不實踐，我們也很難真正理解這些別人總結的經驗，那將是霧里看花。
豐富經驗和軟件設計思想以及軟件工程思想，對軟件開發的重要性真的是如此重要，怪不得我們國家無法開發出大型的高質量的軟件來。