最近幾周一直都在看設計模式之禪，看的過程當中，發現大多數的設計模式在平時編碼過程當中使用到了，當時沒意識到這就是設計模式的一種，翻看自己以前的代碼，有些設計顯然和設計模式的標準有出入，但是個人認為設計模式只是6大設計準則的具體標準實現。在具體項目中，應當靈活的根據設計準則設計出靈活的代碼。只要代碼擴展度高，復雜度低，這就是個好設計。但同時，6大設計準則和23大設計模式我們也要了然於心，好的程序猿的每一行代碼都應是一個很好的設計。

6大設計原則

1.單一職責:(SRP)

一個方法盡量只做一件事，一類只能因為一個原因發起變更。但是在實際的項目中，類的職責劃分是比較難有清晰的界限的，一些好的設計往往會違背單一職責。

裏氏替換原則

為繼承定義了一個規範：

1. 子類必須完全實現父類的方法
2. 子類可以有自己的特性
3. 重載或者重寫父類方法時輸入參數可以被放大
4. 重載或者重寫父類方法時輸出結果可以縮小

依賴倒置原則

1. 高層模塊不依賴於底層模塊，兩者都依賴於抽象
2. 抽象不依賴於細節
3. 細節依賴抽象

底層模塊:不可分割的原子邏輯

高層模塊：多個底層模塊組成合成

在Java中更為精簡的定義就是:面向接口編程，模塊直接的依賴通過抽象發生，實現類之間不直接發生依賴關系，

舉一個反例：司機開車，下圖是司機開奔馳車，如果司機現在換了一輛寶馬車，這個類圖的改動就比較大了

如果更具依賴倒置原則，合理的類圖應當如下

接口隔離原則

接口職責清晰，不要一個接口一堆方法，盡量一個接口只服務一個模塊。

迪米特法則

也被稱之為最少知識原則，不要對外公布自己的太多細節，盡量不要有太多的public屬性，對外只公布一個public方法，保障自己的屬性在自己的控制範圍之內。

開閉原則

對擴展開放，對修改關閉。細致來說：如果代碼需要有變動，應當通過擴展來實現變動，盡量不修改已有的代碼

設計模式之禪(1)-設計準則