程式員之四 設計模式

聊設計模式，有一個內容是必定要掌握的。類圖，一個優秀的架構，如果沒有類圖來輔助，也是一個很恐怖的事情。試想，大牛寫出的代碼，某一天，大牛離職，公司又招一個菜鳥來跟進這個系統。很顯然，菜鳥沒有大局觀，更多的是switch、if/else等控制語句來修改代碼。過不了多久，一團糟的局面又出現了。假如，把優秀的架構都整理成文檔，畫好類圖，事情會變得簡單很多。

類跟類之間的關係就那麼幾種，依賴、關聯、彙總、組合、繼承、實現。一個簡單的類圖只需要處理好這幾種關係。你說有什麼難的？難的就是你肯不肯花時間，以我個人的經驗，畫一畫類圖能讓系統的代碼結構更加清晰，設計能更合理。

當你掌握了類圖，可以看看設計模式了。自從出現了spring
ioc，我覺得建立模式，不再那麼重要了，但是有幾個模式還是應該掌握的。

首當其衝的就是策略模式，當你的代碼中出現過多的條件分支語句，你就應該注意了。是不是可以提煉介面，用工廠管理原則類。而把具體的商務邏輯放到策略中去實現。

其次，模板方法模式，如果你是一個負責人，應該把控好系統核心的、複雜的業務實現。在你不想去事事躬親的時候，定義好模板、鉤子也是一個不錯的選擇。

然後，要說裝飾器模式了，很多時候，我是不願意別人直接改動My Code的，就算一個小小的資訊統計功能。誰能保重，你的修改不會產生新的bug,這是，建議你可以考慮用裝飾器模式。哈哈，其實javaAPI中就用得不錯，在javaIO那一塊，對inputStream的封轉就是很典型的裝飾器模式。

對方法的調用還有很多，像適配器、中介者、橋接等等，作為一個程式員，我覺得對前人的經驗不可不當回事。應該在學習新技術的過程中，時常去看看那些優秀的設計模式。很多時候，你會發現，你寫出的代碼漸漸的滿足了物件導向的6項基本原則。

哈，如果你能靈活的運用設計模式這項工具，評一個進階程式員的職稱應該不為過了吧。