以往的OO特性，封裝、繼承、多態C語言中的模塊化編程，都強調的是代碼的複用。但是設計模式比這高明一些，他強調的是經驗的複用。他們都是以往程序員對編程的理解精華。我們學習設計模式，可以說是讓我們能夠站在巨人的肩膀上編程，設計模式不是發明出來的，是被聰明的人們發現的，這個我也有自己的理解。比如說，在我以前寫C++代碼，做界面的時候，要做一個交互的界面，一般都需要做一些按鈕、文本框之類的組件，我之前沒用用MFC，是根據一個圖形庫自己做的，只有一個windows消息的機制。當時自己通過消息機制做出來了一個按鈕的效果，一點擊就能觸發事件。當時還是比較有成就感的，認爲自己能夠發明車輪了。但是也有一些問題。就是每當我要添加一個按鈕或者修改一個按鈕的時候，都十分的不方便，要改很多的代碼。在我後面學設計模式的時候，發現JDK中也有很多的事件處理機制，他們用的是觀察者模式，我們現在都知道，在java swing編程的時候，我們只需要將組建add到容器中，做一個事件監聽的註冊，步驟十分的加簡單，相對於我編寫的代碼，他的維護性和擴展性都更好，這樣的代碼纔是更有彈性、更符合設計的，這個是設計模式的一大好處。
另外設計模式還有一個好處就是他構造了一些程序員們才懂得的名詞，這就使得那些懂得設計模式的程序員溝通起來更加的方便。人們要把自己的思想全部表達出來並沒有那麼容易的，畢竟還需要經過將思想轉化爲語言在轉化爲思想這麼一個過程，這其中有那個環節出現了紕漏，最後得到的結果可能也和原先的不一樣了。如果我們將好的編程思路封裝成一個個的名詞，這樣不但省去了我們的溝通成本，也讓程序員之間的交流更加的可靠，如同一個老廚師的“加鹽少許”。比如在JDK的java.io包中，有很多的類，初學者面對這麼龐大的類庫是十分頭疼的，但是如果你知道裝飾者模式，知道io的UML，學習io包中的哪些類就會輕鬆很多，會有一種頓悟的感覺。