設計模式之所以存在，是爲了提高代碼的可複用性，可拓展性，可維護性，靈活性。總之一句話就是爲了讓我們開發更方便，更簡潔，更省事兒。這些設計模式都是遵循設計原則而存在，但是不一定每一種設計模式都同時滿足六大設計原則。下面我們先來談談六大設計原則。
- 開閉原則
定義：一個軟件實體，如類，模塊，和方法應該對拓展開放，對修改關閉。
也即是說在有新需求增加的時候，跟該類相關的新功能不要通過修改該類去實現，而是應該增加一個類，來實現該功能。具體的例子在後面的文章中講到設計模式的時候，會提到。這兒一言半語也說不清楚。
- 里氏代換原則
定義一：如果對每一個類型T1的對象o1,都有類型爲T2的對象O2，使得以T1定義的所有程序P，在所有對象O1都替換成O2時，程序P的行爲沒有發生改變，那麼類型T2是T1的子類。
通俗點講：其實這一條是用於約束子類的，子類可以拓展父類的功能，但是不能修改父類的原有功能。其包含了以下四點：
1.子類可以實現父類的抽象方法，但是不能覆蓋父類的抽象方法。
2.子類可以在有父類功能的情況下，增加自己特有的方法。
3.子類重載父類的方法時，方法的形參要比父類的形參更寬鬆。
4.子類的重載父類的方法時，返回值必須比父類的返回值更嚴格，也就是說，子類方法的返回值，必須是父類方法的返回值或者這個返回值的子類。
描述：在不修改父類的情況下還不影響程序的行爲。只有當子類替換掉父類，不用修改父類的情況下還不影響程序的行爲，父類才能被多個類繼承複用，進行新的行爲拓展。如果子類替換掉父類之後，連父類最基本的行爲都不存在了，那其他繼承於父類的子類行爲也就跟着不存在了，那需要改的代碼就更多了，這與我們的期望背道而馳了。 - 依賴倒轉原則
定義：高層模塊不應該依賴底層模塊，二者都應該依賴其抽象，抽象不應該依賴細節，細節應該依賴抽象。
意思是說要面向接口編程，不要面向實現編程。也可以說是不要用具體的類來解決問題，這樣很容易導致類之間的耦合度，需要用接口的方式來弱化類之間的耦合度。其實這個定義是相對於傳統的C，C++等面向過程的開發語言來說的，因爲面向過程的傳統開發模式中，都是上向下依賴。 - 接口隔離原則
定義一：客戶端不應該實現它不需要的接口。
定義二：類之間的依賴應該建立在最小的接口上
這兩種說法其實是殊途同歸，最後的要求都是一樣，意思是說接口儘量細化，裏面不要有不需要的方法，不要一個接口做了多個義務邏輯。這兒可能有人會疑惑，那這不是跟單一職責原則一樣了嗎？其實不是：單一職責重點在職責，接口隔離重點在接口依賴的隔離。另外單一職責主要約束類，其次是方法和接口，主要針對實現的細節，而接口隔離針對的是接口，主要針對抽象，針對整個框架的搭建。 - 迪米特法則
迪米特法則又叫最少知道法則，是強調了弱化類之間的耦合，以便利於複用，一個類被修改不會對有關係的類造成影響。
通俗的來說就是一個類對自己依賴的類知道的越少越好，不論這個類邏輯有多複雜，都儘量在自己內部完成，不會對依賴的類暴露太多的消息。 - 單一職責原則
不要存在多於一個讓類發生變更的原因。如果一個類實現多個功能，有可能因爲一個功能的變更導致其他功能出現問題。
