為什麼會有設計模式?

設計模式（Design Pattern）是一套被反覆使用、多數人知曉的、經過分類的、程式碼設計經驗的總結。

設計模式（Design pattern）代表了最佳的實踐，通常被有經驗的面向物件的軟體開發人員所採用。設計模式是軟體開發人員在軟體開發過程中面臨的一般問題的解決方案。這些解決方案是眾多軟體開發人員經過相當長的一段時間的試驗和錯誤總結出來的。

簡單總結一下就是一種更好的，更優雅的解決問題的方式。但是也有一個需要注意的地方，就是不要為了設計而設計，畢竟我們的出發點是為了解決問題而不是為了設計。

因為本人也是入行不久的小白,而設計原則這個東西也是一個雅俗共賞,千人千面的東西。部落格中寫的也是我在參考了其他人的部落格和書籍之後給出的理解，所以理解難免會有偏差，歡迎評論留言指正，一起學習討論。

設計模式的原則

1.開閉原則(Open Close Principle)

對擴充套件開放，對修改關閉。具體到實際開發就是對程式進行擴充套件的時候，不能去修改原有的程式碼，而是要在原有程式碼的基礎上進行擴充套件。這裡可以用到抽象類和介面。基於頂層方法進行不同的實現，或則在實現裡增加新的方法

2.里氏代換原則（Liskov Substiution Princicle）

里氏代換原則中說，任何基類可以出現的地方，子類一定可以出現。就是父類出現的地方把程式碼換成子類也可以正常執行不受影響。擴充套件的時候也儘量從抽象類繼承，而不要去繼承實現類。這個原則可以參考三人成虎這個典故。在擴充套件的時候儘量不要偏離這個類原有的定義。

3.單一職責原則（Single Responsibility Principle）

這個模式可以用來控制類的粒度，就是一個類不要不要做太多事情，只做一件事。這個原則是實現程式碼高內聚，低耦合的指導方針。不過具體到實際開發還是很難實現的，比如使用者註冊的功能，以前三個方法可能就搞定了，按照這個原則你可能需要把每一個步驟都拆分成獨立的方法，但是這些方法可能一個專案裡就兩三個地方用到，這種情況下是否還有單獨拆出來的必要呢？

4.依賴倒轉原則（Dependence Inversion Principle）

抽象不應該依賴於實現，細節應該依賴於實現。應用到程式碼裡就是一個介面的抽象度要足夠高，不然業務一旦擴充套件之後再去新建立的類再繼承這個類就會發現要實現的功能和基類定義的方法表達的意思差的遠了，需要重新新增加方法，而不是重寫方法。用到這裡類的地方有spring的自動注入。

5.迪米特法則（最少知道原則）（Demeter Principle）

一個實體應該儘可能少的與其他實體之間發生關係。使得系統模組相對獨立。這一點也是微服務的一個重要原則。

6.介面隔離原則（Interface Segregation Principle）

使用多個專門的介面，而不是使用一個介面來完成所有的事情。也就要高度抽象，這個和迪米特法則也是聯絡在一起的。說的再通俗一點就是做自己該做的事情。

7.合成複用原則（Composite Reuse Principle）

在一個新物件裡使用已有的物件，使之成為新物件的一部分，新物件將需要做的大功能分成各個小功能傳達到其他模組來完成，最後完成這大功能。具體到程式碼就是儘量使用組合，不要使用繼承。

設計模式分類

建立型模式（5種）：工廠方法模式，抽象工廠模式，單例模式，建造者模式，原型模式。

結構型模式（7種）：介面卡模式，裝飾器模式，代理模式，外觀模式，橋接模式，組合模式，享元模式。

行為型模式（11種）：策略模式、模板方法模式、觀察者模式、迭代子模式、責任鏈模式、命令模式、備忘錄模式、狀態模式、訪問者模式、中介者模式、直譯器模式。

還有另外兩個，併發型模式和執行緒池模式。