在開始學習編程的時候，也看見過設計模式有關的書，那時感覺不到設計模式的重要性，感覺不用照樣可以實現相應的功能，隨着學習的深入對設計模式有了更深入的認識。沒有設計模式只能蓋個小土房，而設計模式是要蓋高樓大廈的。
一、單一職責原則(Single Responsibility Principle, SRP);
英文解釋：There should never be more thanone reason for a class to change.通俗點說就是一個類只幹一件事，很適合現在工業的分工細化等等；
在我們寫代碼的過程中肯定會有修改的地方，如果一個類集成很多種動作，那麼我們修改起來就會很麻煩，這個時候就需要單一職責啦，一個類只負責一個職責，當需要添加或修改職責時，我只需要修改相應的職責類就行了，不需要關注其他的，這樣我們就提高了代碼的可維護性。
優點：1、類的複雜性降低，各司其職，互不干涉。
2、可讀性提高，結構清晰。
3、和維護性提高，接口變更，只對相應的實現類有影響。
注意：單一職責這個“職責”在實際中並沒有實際的定義，沒有明確的邊界定義。這就需要自己看情況而定啦，切記不可過分細化，這樣不但沒有得到想要的結果，反而增加了程序的複雜性。
二、里氏替換原則(Liskov Substitution Principle, LSP)；
里氏替換原則是解決把繼承中利最大化，弊最小化的問題。
繼承有以下優點：1、代碼共享，減少代碼量，每個子類都擁有父類的屬性和方法。
2、提高代碼的重用。
3、子類類似父類，但又不同於父類，子類可以有自己的特色。
4、提高代碼的擴展性。
5、提高產品的開放性。
缺點：1、繼承是侵入性的，一旦繼承了父類就必須接受父類的屬性和方法。
2、降低代碼的靈活性，子類在父類的基礎之上，會受到父類的約束。
3、增強程序的耦合性，一旦父類的屬性修改，子類必須進行相應的或者更大工作量的更改。
英文解釋：If for each object o1 of type S there is an object o2of type T such for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substitued for o2 then S is a subtype of T.。所有引用基類的地方都必須透明的使用其子類的對象。
里氏替換原則四句話：
1、子類必須完全實現父類的方法。在類中調用其他類時務必要使用父類或者接口，如果不能使用父類或者接口，則說明類的設計已經違背了LSP原則。如果子類不能完整的實現父類的方法，或者父類的某些方法在子類中已經發生“畸變”，則建議斷開父類繼承關係，採用依賴、聚集、組合等關係替代繼承。
2、子類可以有自己的個性。
3、覆蓋或者實現父類的方法時，輸入參數可以被放大。如果子類的前置條件較小，子類在沒有覆蓋父類的方法前提下，子類方法被執行了，這回引起業務邏輯的混亂。在實際中，父類一般是抽象類，而子類是實現類，傳遞一個這樣的實現類，會扭曲父類的意圖，引起意想不到的邏輯混亂。
4、覆蓋或者實現父類的方法時輸出的結果可以被縮小。
採用里氏替換原則的目的就是增強程序的健壯性，版本升級時可以保持非常好的兼容性。即使增加子類，原有的子類還可以繼續運行，在實際項目中，每個子類對應不同的業務含義，使用父類作爲參數，傳遞不同的子類完成不同的業務邏輯，相當完美。
三、依賴倒置原則(Dependence Inversion Principle, DIP)；
High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions.
高層模塊不應該依賴低層模塊，兩者都應該依賴抽象（接口和抽象類）。
抽象不應該依賴細節。
細節應該依賴抽象。
在Java中的表現爲：模塊間的依賴通過抽象發生，實現類之間不發生直接的依賴關係，其依賴關係通過接口或者抽象類產生；抽象不依賴於實現類；實現類依賴抽象類或者接口；也就是面向接口的編程。
依賴倒置可以減少類間的耦合性，提高穩定性，降低並行開發的風險，提高代碼的可維護性和擴展性。
通過上圖可以得出，如果我們在增加汽車類的時候，只需要實現ICar接口就行，對其他的任何東西都不影響，這就增加了程序的健壯性。當周圍環境變化時，其他的類任然能做到渾然不動。
依賴有三種寫法：構造函數傳遞依賴對象；Setter方法傳遞依賴對象；接口聲明依賴對象；
其本質就是通過抽象是各個類或者模塊的實現彼此獨立，不互相影響，實現模塊間的鬆耦合，我們在項目中使用需要遵循如下規則：1、每個類儘量都有接口和抽象類，或者抽象類和接口兩者都具備；
2、變量的表面類型儘量是接口或者抽象類；
3、任何類都不應該從具體類派生；
4、儘量不要覆寫基類的方法；
5、結合里氏替換原則使用；
