最近在看一本叫做《大話設計模式》的書，感覺本書的作者是下了功夫了，寫的不錯，通俗易懂而且表達很直接很明確，跟之前讀過的幾本書感覺不太一樣，之前讀的幾本書作者彎彎繞繞，最後也不知道到底想說什麼。 為了更好的鞏固自己學到的東西，也為了是自己能堅持讀完這本書，我決定把書中的設計模式按照自己的理解以文字+程式碼的方式展現，如有不對的地方還請多多指教。只有大家相互交流切磋，才能取得進步。 在介紹設計模式之前，我先先介紹一下自己的工作經歷，也算是與大家分享一下自己家的職業道路吧。 我做軟體也有三年了，一直用c/c++,之前工作過的都是一些比較大的公司，這些大公司基本上都有自己成熟的產品和軟體架構，我的工作方式基本上就是頭兩三個月熟悉公司原有程式碼（另加一些雜七雜八的小活），這段時間基本上是最痛苦的那段時間，程式碼不熟悉，什麼都做不了，為了解決一個簡單的問題可能要花整整一天的時間來讀相關的程式碼（讀別人的程式碼真的很吃力），同樣的問題老員工可能花上個1-2個小時就能輕鬆搞定，當時 深深的懷疑過自己的能力，感覺身邊的“老員工”（所謂的老員工，其實就是來公司比我早，工作年限不見得比我長）都好牛X。 平安度過頭兩三個月之後，會進入到一個相對比較平靜的時期，這時候程式碼比較熟悉了，解決問題也開始有點思路了，自我感覺還不錯，對身邊“老員工”狂熱的崇拜之情也慢慢冷卻下來。 這個時期的主要工作（也是在公司未來的主要工作）是在公司原有程式碼的基礎上進行一些修修補補，只知道要實現某個功能只需要在原有程式碼的某個地方加上相應的程式碼就行，至於公司程式碼的設計模式只有三個字—-不知道，至於公司為什麼要選用這種模式更是一無所知。其實這一時期是大多數程式設計師都會經歷的瓶頸期，很多人會覺得活得很舒服，就像溫水煮青蛙一樣，這時候的水溫是最合適最舒服的，很多程式設計師都是從這裡開始停滯不前的。當然，並不是說這段時期就一定一無所獲，隨著工作時間的增長，還是會有所收穫的，列如，本人就在此期間學會了用windebug和debugview等相關工具來排查問題。但相對於時間來說，這些收穫確實有點得不償失。 嘮叨到此為止，開始今天的正題——設計模式。 沒接觸設計模式之前感覺沒什麼，三年的編碼工作也安安穩穩的度過了，並沒有覺得設計模式對我的工作有什麼影響。一個偶然的機會我接觸到了設計模式，感覺就好像打開了通往另一個世界的大門，自己的視野一下子開闊起來，這時候回看自己之前寫的程式碼，簡直像shi一樣，頓時覺得無地自容。 那麼什麼是設計模式？說實話我也不知道，因為我也是剛剛接觸，只瞭解一些皮毛，不敢妄自菲薄。只能說說現階段自己現在對設計模式的理解。 我們都知道程式設計是為了解決問題。解決同一個問題，可能會有很多種的編碼方式，你可以只寫一個main函式，所有的功能程式碼都在這個main函式裡，你也可以根據不同的功能編寫不同的函式介面，然後在main函式裡去呼叫相應的介面函式，當然，你也可以使用面向物件的程式設計方式，封裝幾個不同的類來實現。那麼哪種方式是最好的呢？其實沒有最好的。因為隨著問題和需求的變化，之前採用的編碼方式可能就不合適了。 設計模式會教給我們應該如何分析問題或需求，並在分析的基礎上給出我們一個最優的編碼方式。就好比十一黃金週，我們打算去香港遊玩，但我們應該怎麼去香港呢？高鐵or飛機？這時候，會有一個叫”設計模式”的東西告訴你，十一期間是西太平洋的颱風多發季，坐飛機的話受颱風的影響會比較大，高鐵雖然慢但時間也在你的接受範圍內，所以最好是乘坐高鐵，而且黃金週結束後可定會有一個返程高峰，最好把回來的高鐵票也買上，以免耽誤返程。 這篇文章雖然是寫設計模式，但更多的內容是介紹自己的職業經歷，其實跟設計模式沒什麼關係，下一篇我們就不寫這麼多廢話了，直接從簡單工廠模式和策略模式入手。