前言
- 先說下一下為什么決定來寫關于設計模式的文章，本人也是從事開發很多年了，很多人肯定都曾有過這樣的想法，就是把設計模式背下來，到時候項目用到的時候就套用下，往往用到的時候早就忘了怎么寫了，或許只是簡單記住幾個寫法，現在看來這并不是真正的理解，套用不等于理解，真正理解之后會在思維里面形成一種模型，在做架構設計、封裝代碼時候會自然的把場景帶入，去理解每一種模式的場景、優點、缺點，才能更好的運用。
- 設計模式是一套被反復使用、多數人知曉的、經過分類編目的、代碼設計經驗的總結。使用設計模式是為了可重用代碼、讓代碼更容易被他人理解、保證代碼可靠性。
1.單一職責原則（SRP）
簡單的說就是：一個類中應該是一組相關性很高的函數、數據的封裝。兩個不一樣的功能不應該放在一個類中。
這個原則沒有具體的劃分界限，需要根據個人經驗，具體業務邏輯而定。這也是優化代碼的第一步。試想一下，如果所有的功能寫在一個類里，那么這個類會越來越大，越來越復雜，越不易修改維護。那么根據功能，各自獨立拆分出來，豈不是邏輯會清晰些。
2.開閉原則（OCP）
定義：軟件中的對象（類、模塊、函數等）應該對于擴展是開放的，但是對于修改是封閉的。
當軟件需要變化時，我們應該盡量通過擴展的方式實現變化，而不是通過修改原有的代碼來實現。因為直接的修改，可能會影響已有的正常代碼。不利于出現錯誤時排除問題。當然實際開發中，修改原有代碼與擴展代碼是同時存在的。但應盡量以擴展為主。
3.里氏替換原則（LSP）
定義：所有引用父類的地方，必須能使用子類的對象。簡單地說就是將父類替換為他的子類是不會出現問題，反之，未必可以。
那么里氏替換原則就是依賴于面向對象語言的繼承與多態。核心原理是抽象。這里列舉一下繼承的優缺點：
優點：
（1）代碼重用，減少創建類的成本，每個子類都擁有父類的方法與屬性。
（2）子類與父類基本相似，但與父類又有所區別。
（3）提高代碼的可擴展性。
缺點：
（1）繼承是侵入性的，只要繼承就必須擁有父類所有的屬性與方法。
（2）可能造成子類代碼冗余、靈活性降低。開閉原則和里氏替換原則是生死相依的、不離不棄的。他們都強調了抽象這一重要的特性。
4.依賴倒置原則（DIP）
定義：指代一種特定的解耦方式，使得高層次的模塊不依賴于低層次的模塊的實現細節的目的。他有一下幾個關鍵點：
（1）高層模塊不依賴于低層模塊，應該都依賴其抽象。
（2）抽象不依賴細節。
（3）細節應依賴抽象。解釋：在Java中，抽象就是指接口或者抽象類，兩者都是不能直接被實例化的；細節就是實現類，實現接口或者繼承抽象類而產生的就是細節，也就是可以加上一個關鍵字new產生的對象。高層模塊就是調用端，底層模塊就是具體實現類。
依賴倒置原則在Java中的表現就是：模塊間通過抽象發生，實現類之間不發生直接依賴關系，其依賴關系是通過接口或者抽象類產生的。如果類與類直接依賴細節，那么就會直接耦合，那么當修改時，就會同時修改依賴者代碼，這樣限制了可擴展性。
5.接口隔離原則（ISP）
定義：類間的依賴關系應該建立在最小的接口上，將龐大、臃腫的接口拆分成更小的、更具體的接口。目的是系統的解耦，從而更容易重構、更改和重新部署。
6.迪米特原則（LOD）
定義：一個類應該對自己需要耦合或者調用的類知道的最少，類的內部如何實現與調用者或者依賴者沒有關系，調用者或依賴者只需知道他需要的方法，其他可以一概不管。這樣使得系統具有更低的耦合與更好的可擴展性。
這六個原則，可以使我們在應用的后續升級、維護中更加方便、輕松應對。讓我們的軟件更加靈活。
總結
在我看來設計模式就像軍人手中的武器，只有足夠鋒利才能所向披靡，光看書看文章是不夠的，要自己在項目里真正的場景去使用才能更好的理解，包括在工程師成長的道路中，無論作為高級開發還是架構師都是需要對這些要理解銘記于心，才能寫出更好用的代碼，更穩定擴展性更強的架構，才能做到心中有劍，落葉飛花皆是兵器的境界。
