Java設計模式-設計模式的六種原則，java設計模式

Java設計模式-設計模式的六種原則，java設計模式

        所謂無招勝有招，練一門功夫分為內功和外功。外功好比招式，就是所謂的23種設計模式。而內功呢，就是心法，那就是這6種法則。光會外功那是花拳繡腿，內功修為才是境界。如此眾多的設計模式，學完2遍，3遍可能也會忘的只記得單例和原廠模式。但是只要原則記住，在以後的設計中，有意無意就會用的設計模式的精髓。

六種設計原則

單一職責原則

不要存在多於一個導致類變更的原因。通俗的說，即一個類只負責一項職責。  問題由來：類T負責兩個不同的職責：職責P1，職責P2。當由於職責P1需求發生改變而需要修改類T時，有可能會導致原本運行正常的職責P2功能發生故障。一句話總結：不能為圖代碼量少，把牛頭馬嘴一起往一個類塞

裡氏替換原則

1.子類可以實現父類的抽象方法，但不能覆蓋父類的非抽象方法。

2.子類中可以增加自己特有的方法。

3.當子類的方法重載父類的方法時，方法的前置條件（即方法的形參）要比父類方法的輸入參數更寬鬆。

4.當子類的方法實現父類的抽象方法時，方法的後置條件（即方法的返回值）要比父類更嚴格。

一句話總結：盡量不要重寫父類的已經實現了的方法，可以用介面等其他方法繞過

依賴倒置原則

高層模組不應該依賴低層模組，二者都應該依賴其抽象；抽象不應該依賴細節；細節應該依賴抽象。

這裡用一個列子來說明：

import java.util.LinkedList;import java.util.Queue;interface IEAT{public void eat();//抽象吃這個動作}class EatApple implements IEAT{@Overridepublic void eat() {//這裡是吃蘋果System.out.print("eat a apple");}}class EatWater implements IEAT{@Overridepublic void eat() {// 這裡是吃水System.out.print("dringk water");}}public class Human{public void dosomething(IEAT ieat)//我愛吃東西，吃什麼呢，看傳入什麼{ieat.eat();}/*public void dosomething(String food)//我愛吃東西，吃什麼呢，看傳入什麼{if(food.equals("apple")){//吃蘋果}if(food.equals("water")){//喝水}}*/public static void main(String[] args){Human human=new Human();/*human.dosomething("apple");human.dosomething("water"); *///給你吃個蘋果human.dosomething(new EatApple());//再給你喝點水human.dosomething(new EatWater());}}

其中注釋的就是我們常用的方法。這種方法非常不適於擴充，因為如果要吃香蕉，吃西瓜，又要在dosomething裡面寫一堆判斷。寫著寫著就混了。

因此一句話總結：多用抽象的介面來描述相同的動作，降低實現這個動作的人和物之間的耦合度

介面隔離原則

用戶端不應該依賴它不需要的介面；一個類對另一個類的依賴應該建立在最小的介面上。 問題由來：類A通過介面I依賴類B，類C通過介面I依賴類D，如果介面I對於類A和類B來說不是最小介面，則類B和類D必須去實現他們不需要的方法。一句話總結：就好比魚和人兩個類，魚是遊泳和腮呼吸兩個動作，人是走路和吃飯兩個動作，這些動作不能寫在一個介面裡面，把這四個動作都包含了。要拆成專門對魚和人的兩個介面才行。

迪米特法則

迪米特法則又叫最少知道原則，最早是在1987年由美國Northeastern University的Ian Holland提出。通俗的來講，就是一個類對自己依賴的類知道的越少越好。也就是說，對於被依賴的類來說，無論邏輯多麼複雜，都盡量地的將邏輯封裝在類的內部，對外除了提供的public方法，不對外泄漏任何資訊。

這個有點不好記，總結就是：father1<-child1,father2<-child2,father1和father2是的手下， father1盡量通過father2去訪問child2, 不要直接在類裡面訪問child2. 下屬怎麼能隨便去領導家的孩子呢，小心別人說你拐賣 

開閉原則

這個沒啥好說的：盡量通過擴充軟體實體的行為來實現變化，而不是通過修改已有的代碼來實現變化。