前言
在我平時的學習與項目工作中，經常會糾結于類的架構搭建，以及類間的關系梳理，而當我通過檢視一些牛人的代碼解釋時總會有一種有一種豁然開朗之感，感覺别人寫的代碼層次清晰，易于了解。久而久之，我确實感覺到了設計模式在項目工作中的重要性，是以這段時間我會簡單的學習Java中的設計模式，當然深刻的了解設計模式需要有足夠的項目經驗，目前我隻希望大緻了解各種設計模式功能，希望在以後的項目中能夠使用并加深了解。
什麼是設計模式？
模式描述的是我們周圍經常重複發生的問題，以及該問題的解決方案的核心。而模式更是一種經驗的的積累與總結 ， 是以通過模式，我們可以站在巨人的肩膀上去思考問題、解決問題，熟練使用設計模式可以提高我們的工作效率，改善産品品質，最終帶來經濟效益。是以對于任何想開發出靈活高效、健壯的軟體産品的個人或團體，熟練掌握并正确使用設計模式都是必須掌握的基本技能。
設計模式的六大原則
對于設計模式來說，為什麼這個模式要這樣解決這個問題，而另一個模式要那樣，它們背後都遵循的就是永恒的設計原則。 可以說，設計原則是設計模式的靈魂。
1.單一職責原則(SRP)
“對于一個類而言，僅有一個能夠使它變化的原因”，也就是說不要把原因變化各不相同的職責放在一個類中，而應該 将不同的職責配置設定給不同的類，使單個類的職責盡量單一，避免類間互相影響。
例如 ：參考下圖中的設計，圖形計算程式隻使用了正方形的 Area() 方法，永遠不會使用 Draw() 方法，而它卻跟 Draw 方法關聯了起來。這違反了單一原則，如果未來因為圖形繪制程式導緻 Draw() 方法産生了變化，那麼就會影響到本來毫不關系的圖形計算程式。
那麼我們該怎麼做呢？如下圖，将不同的職責配置設定給不同的類，使單個類的職責盡量單一，就隔離了變化，這樣他們也不會互相影響了
2.裡氏替換原則(LSP)
“子類型必須能夠替換掉它們的基類型。”也就是說繼承中的“ IS A ”關系是必須保證的，否則還算什麼繼承啊！如果違反了 LSP 原則，常會導緻在運作時 (RTTI) 的類型判斷違反”開放-封閉原則” 。
裡氏代換原則是對“開放-封閉”原則的補充。實作“開閉”原則的關鍵步驟就是抽象化。而基類與子類的繼承關系就是抽象化的具體實作，是以裡氏代換原則是對實作抽象化的具體步驟的規範。裡氏替換原則中，子類對父類的方法盡量不要重寫和重載。因為父類代表了定義好的結構，通過這個規範的接口與外界互動，子類不應該随便破壞它。
3.依賴倒置原則(DIP)
面向接口程式設計，依賴于抽象而不依賴于具體。寫代碼時用到具體類時，不與具體類互動，而與具體類的上層接口互動。
例如 ：參考下圖的設計，一個開關跟燈直接連接配接在一起了，也就是說開關依賴于燈的打開和關閉方法，那麼如果我想用這個開關也可以打開其他東西呢，比如電視、音響。顯然這個設計是無法滿足這個要了，因為我們依賴了具體而不是抽象，這個開關已經等價于“燈的開關”。
那麼我們該如何來設計一個通用的開關呢？參考下圖的設計， OK ！現在我們不僅可以打開燈，還可以打開電視和音響，甚至未來任何實作了“開關接口”的任何東西。
4.接口隔離原則(ISP)
每個接口中不存在子類用不到卻必須實作的方法，如果不然，就要将接口拆分。使用多個隔離的接口，比使用單個接口（多個接口方法集合到一個的接口）要好。
例如 ：參考下圖的設計，在這個設計裡，取款、存款、轉帳都使用一個通用界面接口，也就是說，每一個類都被強迫依賴了另兩個類的接口方法，那麼每個類有可能因為另外兩個類的方法 ( 跟自己無關 ) 而被影響。拿取款來說，它根本不關心“存款操作”和“轉帳操作”，可是它卻要受到這兩個方法的變化的影響，真是土鼈！！！
那麼我們該如何解決這個問題呢？參考下圖的設計，為每個類都單獨設計專門的操作接口，使得它們隻依賴于它們關系的方法，這樣就不會互相影響，也就不會在發生土鼈的事情了！
5.迪米特法則(最少知識原則)
一個類對自己依賴的類知道的越少越好。無論被依賴的類多麼複雜，都應該将邏輯封裝在方法的内部，通過public方法提供給外部。這樣當被依賴的類變化時，才能最小的影響該類。 迪米
特法則就要求類“小氣”一點，盡量不要對外公布太多的 public 方法和非靜态的 public 變量， 盡量内斂， 多使用 private,package-private、protected 等通路權限。
6.開放封閉原則(OCP)
“軟體實體 ( 類、子產品、函數等 ) 應該是可以擴充的，但是不可修改。”即 可以随便增加新的類，但是不要修改原來的類
例如 ：如下圖，有一個用戶端程式通過資料通路接口操作資料，對于這套系統來說，一開始計劃使用的是 SQL Server 或 Oracle 資料庫，但是後來考慮到成本，改用免費的 MySQL ；那麼對于用戶端程式來說，後來資料的擴充對它沒有任何影響，它在不知不覺間就用上了免費好用的 MySQL 資料庫，這全要感謝 OCP 原則。
設計模式分類
-
建立型模式：關注對象的建立過程。
工廠方法模式、抽象工廠模式、單例模式、建造者模式、原型模式。
-
結構型模式： 關注對象和類的組織。
擴充卡模式、裝飾器模式、代理模式、外觀模式、橋接模式、組合模式、享元模式。
-
行為型模式：關注系統中對象之間的互相互動，研究系統在運作時對象之間的互相通信和協作，進一步明确對象的職責。
政策模式、模闆方法模式、觀察者模式、疊代器模式、責任鍊模式、指令模式、備忘錄模式、狀态模式、通路者模式、中介者模式、解釋器模式。
好了簡單的介紹了設計原則與設計模式分類，接下來将會逐漸介紹各個設計模式。
文章借鑒： http://www.cnblogs.com/justinw/archive/2006/11/28/574573.html