設計模式（一）

好久之前看設計模式的時候，也沒有看的太透徹，一直到如今，仍是雲裏霧裏，並且雜七雜八的知識早就忘得差很少了。

最近買了一本最經典的最基礎的設計模式的書--《大話設計模式》，就此趁這機會在重學一遍，好好理一理思路。

六大原則

 

一、單一職責原則

字面理解，是要保持功能的單一，每一個類或方法要儘可能把實現的功能拆分出來，這樣能保證低耦合，還能減小代碼的重複量。

好比，從學生表中獲取成績大於90的學生，修改等級爲A，若是放在一個方法裏實現，那獲取成績大於90分的學生的功能就要從新寫一個方法。

最好的辦法是，將查詢和修改寫成兩個方法，避免重用。這在mvc三層設計裏就是常用的。

二、里氏替換原則

任何基類能夠出現的地方，子類必定能夠出現。

-->里氏替換原則規範（請參照：http://blog.csdn.net/hfreeman2008/article/details/52344343）

-->1）子類必須徹底實現父類的方法

-->2）子類能夠有本身獨有的方法和屬性

-->3）覆蓋或實現父類的方法時輸入參數能夠被放大

-->4）覆蓋或實現父類的方法時輸出結果能夠被縮小

三、依賴倒轉原則

抽象不該該依賴細節，細節應該依賴於抽象。高層模塊不該該依賴於低層模塊，二者都應該依賴於抽象。

若是是高層依賴於低層，在低層模塊須要更改時也須要更改高層模塊，會致使模塊的複用性下降並且大大提升了開發的成本。因此用依賴倒轉，即便實現細節不斷變更，只要抽象不變，客戶程序就不須要變化。這大大下降了客戶程序與實現細節的耦合度。

四、接口隔離原則

客戶端不該該依賴它不須要的接口；一個類對另外一個類的依賴應該創建在最小的接口上。

通常規則：

• 一個接口只服務於一個子模塊或業務邏輯
• 接口儘可能簡潔
• 接口儘可能不要更改

好比在簡書上看到的一個例子：一個動物接口，一隻狗，一隻雞，若是接口裏定義了飛的方法，狗對象並不能使用。因此要再定義一個接口，將飛的方法放進去，由雞來實現。

五、迪米特法則

一個軟件實體應當儘量少的與其餘實體發生相互做用。就是說一個對象應當對其餘對象有儘量少的瞭解,不和陌生人說話。

1）優先考慮將一個類設置成不變類。

2）儘可能下降一個類的訪問權限。

3）謹慎使用Serializable。

4）儘可能下降成員的訪問權限。

六、開閉原則

軟件實體，包括類、函數、模塊等，能夠擴展，但不能修改。簡單來講就是能夠添加，不能改動。開閉原則中「開」，是指對於組件功能的擴展是開放的，是容許對其進行功能擴展的；開閉原則中「閉」，是指對於原有代碼的修改是封閉的，即修改原有的代碼對外部的使用是透明的。