詳解java設計模式之六大原則

目錄

一、單一職責原則

1、單一職責定義

單一職責原則：一個(gè)類(lèi)只負責一個(gè)功能領(lǐng)域中的相應職責，或者可以定義為：就一個(gè)類(lèi)而言，應該只有一個(gè)引起它變化的原因。

單一職責原則告訴我們：一個(gè)類(lèi)不能太“累”！在軟件系統中，一個(gè)類(lèi)承擔的職責越多，它被復用的可能性就越小，而且一個(gè)類(lèi)承擔的職責過(guò)多，就相當于將這些職責耦合在一起，當其中一個(gè)職責

變化時(shí)，可能會(huì )影響其他職責的運作，因此要將這些職責進(jìn)行分離，將不同的職責封裝在不同的類(lèi)中，即將不同的變化原因封裝在不同的類(lèi)中，如果多個(gè)職責總是同時(shí)發(fā)生改變則可將它們封裝在同一類(lèi)中。

2、單一職責優(yōu)點(diǎn)

1）降低了類(lèi)的復雜度。一個(gè)類(lèi)只負責一項職責比負責多項職責要簡(jiǎn)單得多。

2) 提高了代碼的可讀性。一個(gè)類(lèi)簡(jiǎn)單了，可讀性自然就提高了。

3) 提高了系統的可維護性。代碼的可讀性高了，并且修改一項職責對其他職責影響降低了，可維護性自然就提高了。

4) 變更引起的風(fēng)險變低了。單一職責最大的優(yōu)點(diǎn)就是修改一個(gè)功能，對其他功能的影響顯著(zhù)降低。

3、案例說(shuō)明

在網(wǎng)上找了個(gè)比較好理解，也比較符合實(shí)際開(kāi)發(fā)中用來(lái)思考的小案例。

有一個(gè)用戶(hù)類(lèi)，我們先看它的接口：

這個(gè)接口是可以?xún)?yōu)化的，用戶(hù)的屬性（Property）和用戶(hù)的行為（Behavior）沒(méi)有分開(kāi)，這是一個(gè)嚴重的錯誤！非常正確，這個(gè)接口確實(shí)設計得一團糟，應該把用戶(hù)的信息抽取成一個(gè)BO（Bussiness Object，業(yè)務(wù)對象），把行為抽取成一個(gè)BIZ(Business Logic，業(yè)務(wù)邏輯)，按照這個(gè)思路對類(lèi)圖進(jìn)行修正，如圖1-2所示。

重新拆封成兩個(gè)接口，IUserBO負責用戶(hù)的屬性，簡(jiǎn)單地說(shuō)，IUserBO的職責就是收集和反饋用戶(hù)的屬性信息；IUserBiz負責用戶(hù)的行為，完成用戶(hù)信息的維護和變更。

然后IUserInfo來(lái)實(shí)現這兩個(gè)接口，重寫(xiě)方法。

代碼清單1-1 分清職責后的代碼示例

.......
 
IUserBiz userInfo = new UserInfo();
 
//我要賦值了，我就認為它是一個(gè)純粹的BO
 
IUserBO userBO = (IUserBO)userInfo;
 
userBO.setPassword("abc");
 
//我要執行動(dòng)作了，我就認為是一個(gè)業(yè)務(wù)邏輯類(lèi)
 
IUserBiz userBiz = (IUserBiz)userInfo;
 
userBiz.deleteUser();
 
.......

思考：上面這樣是單一職責原則嗎？當然不是了，你實(shí)現了兩個(gè)接口，不還是把行為和屬性寫(xiě)在一個(gè)類(lèi)了，和最上面又有什么區別呢，這里只能說(shuō)實(shí)現了接口隔離原則（下面會(huì )說(shuō)）

那如何來(lái)確保單一原則，在實(shí)際的使用中，我們更傾向于使用兩個(gè)不同的類(lèi)：一個(gè)是IUserBO， 一個(gè)是IUserBiz很簡(jiǎn)單如圖所示：

4、自己理解

單一職責原則有兩個(gè)難點(diǎn)：

1) 職責劃分：

一個(gè)職責一個(gè)接口，但問(wèn)題是“職責”是一個(gè)沒(méi)有量化的標準，一個(gè)類(lèi)到底要負責那些職責？這些職責該怎么細化？細化后是否都要有一個(gè)接口或類(lèi)？這些都需要從實(shí)際的項目去考慮。

比如上面寫(xiě)成一個(gè)類(lèi)他的單一職責就是修改用戶(hù)信息，為什么一定要分修改行為和修改屬性。那是不是又可以在細分修改密碼和修改屬性呢？

2）類(lèi)的冗余

如果可以追求單一職責也是沒(méi)有必要的，本來(lái)一個(gè)類(lèi)可以搞定的實(shí)現，如果非得修改用戶(hù)名一個(gè)類(lèi)，修改密碼一個(gè)類(lèi)來(lái)實(shí)現單一原則，這樣也會(huì )讓你的類(lèi)變得非常多，反而不容易維護。

我自己的感悟：

1）首先要培養單一職責的思想，特別是如果代碼可以復用的情況下經(jīng)常思考能不能用單一職責原則來(lái)劃分類(lèi)。

2) 類(lèi)的單一職責實(shí)現在好多時(shí)候并不切實(shí)際，但是方法上一定要保持單一職責原則。比如你修改密碼的方法就是用來(lái)修改密碼。這樣做有個(gè)很大的好處就是便于代碼調試，容易將代碼的Bug找出來(lái)，一個(gè)方法只完成

一件事情，相對調試能簡(jiǎn)單很多，讓其他人員能更快更好的讀懂代碼、理解這個(gè)類(lèi)或者方法的功能。

二、里氏代換原則

這個(gè)和單一職責原則比起來(lái)，顯然就好理解多了，而且也不那么模糊不清。

1、定義

官方定義：所有引用基類(lèi)（父類(lèi)）的地方必須能透明地使用其子類(lèi)的對象。

簡(jiǎn)單理解就是：子類(lèi)一般不該重寫(xiě)父類(lèi)的方法，因為父類(lèi)的方法一般都是對外公布的接口，是具有不可變性的，你不該將一些不該變化的東西給修改掉。

是不是感覺(jué)這個(gè)原則不太招人喜歡，因為我們在寫(xiě)代碼的時(shí)候經(jīng)常會(huì )去重寫(xiě)父類(lèi)的方法來(lái)滿(mǎn)足我們的需求。而且在模板方法模式，缺省適配器，裝飾器模式等一些設計模式都會(huì )采用重寫(xiě)父類(lèi)的方法。

怎么說(shuō)呢，里氏代換原則的主要目的主要是防止繼承所帶來(lái)的弊端。

繼承的弊端：

繼承作為面向對象三大特性之一，在給程序設計帶來(lái)巨大便利的同時(shí)，也帶來(lái)了弊端。

繼承會(huì )增加了對象間的耦合性，如果一個(gè)類(lèi)被其他的類(lèi)所繼承，則當這個(gè)類(lèi)需要修改時(shí)，必須考慮到所有的子類(lèi)，并且父類(lèi)修改后，所有涉及到子類(lèi)的功能都有可能會(huì )產(chǎn)生故障。

2、案例說(shuō)明

SomeoneClass類(lèi)，其中有一個(gè)方法，調用了某一個(gè)父類(lèi)的方法。

//某一個(gè)類(lèi)
public class SomeoneClass {
    //有某一個(gè)方法，使用了一個(gè)父類(lèi)類(lèi)型
    public void someoneMethod(Parent parent){
        parent.method();
    }
}

父類(lèi)代碼

public class Parent {

    public void method(){
        System.out.println("parent method");
    }
}

SubClass子類(lèi)把父類(lèi)的方法給覆蓋。

public class SubClass extends Parent{

    //結果某一個(gè)子類(lèi)重寫(xiě)了父類(lèi)的方法，說(shuō)不支持該操作了
    public void method() {
        throw new UnsupportedOperationException();
    }
    
}

測試類(lèi)

/**這個(gè)異常是運行時(shí)才會(huì )產(chǎn)生的，也就是說(shuō)，我的SomeoneClass并不知道會(huì )出現這種情況，結果就是我調用下面這段代碼的時(shí)候，
 *本來(lái)我們的思維是Parent都可以傳給someoneMethod完成我的功能，我的SubClass繼承了Parent，當然也可以了，但是最終這個(gè)調用會(huì )拋出異常。
 */
public class Client {

    public static void main(String[] args) {
        SomeoneClass someoneClass = new SomeoneClass();
        someoneClass.someoneMethod(new Parent());
        someoneClass.someoneMethod(new SubClass());
    }
}

這就相當于埋下了一個(gè)個(gè)陷阱，因為本來(lái)我們的原則是，父類(lèi)可以完成的地方，我用子類(lèi)替代是絕對沒(méi)有問(wèn)題的，但是這下反了，我每次使用一個(gè)子類(lèi)替換一個(gè)父類(lèi)的時(shí)候，我還要擔心這個(gè)

子類(lèi)有沒(méi)有給我埋下一個(gè)上面這種炸彈。

3、自己理解

感覺(jué)自己在開(kāi)發(fā)中不太會(huì )出現上面這么愚蠢的錯誤。理由：

1）自己水平有限，平時(shí)在開(kāi)發(fā)中使用繼承的時(shí)候都是基礎API的類(lèi)然后重寫(xiě)，很少繼承自己寫(xiě)的類(lèi)，一般都是實(shí)現接口比較多。

2）第二就算我用了繼承，我在傳參的時(shí)候我只要稍微注意下就應該知道這個(gè)方法的參數是Parent，而如果我要放入SubClass時(shí)，就應該考慮自己有沒(méi)有重寫(xiě)這個(gè)方法，如果重寫(xiě)這樣肯定不行。所以也不多發(fā)生上面的錯誤了。

所以總的來(lái)說(shuō)，要知道繼承的這個(gè)隱患，在開(kāi)發(fā)中注意就是。

三、接口隔離原則

1、定義

當一個(gè)接口太大時(shí)，我們需要將它分割成一些更細小的接口，使用該接口的客戶(hù)端僅需知道與之相關(guān)的方法即可。

為什么要這么做呢？

其實(shí)很好理解，因為你實(shí)現一個(gè)接口就是實(shí)現它所有的方法，但其實(shí)你并不需要它的所有方法，那就會(huì )產(chǎn)生：一個(gè)類(lèi)實(shí)現了一個(gè)接口，里面很多方法都是空著(zhù)的，只有個(gè)別幾個(gè)方法實(shí)現了。

這樣做不僅會(huì )強制實(shí)現的人不得不實(shí)現本來(lái)不該實(shí)現的方法，最嚴重的是會(huì )給使用者造成假象，即這個(gè)實(shí)現類(lèi)擁有接口中所有的行為，結果調用方法時(shí)卻沒(méi)收獲到想要的結果。

2、案例說(shuō)明

比如我們設計一個(gè)手機的接口時(shí)，就要手機哪些行為是必須的，要讓這個(gè)接口盡量的小，或者通俗點(diǎn)講，就是里面的行為應該都是這樣一種行為，就是說(shuō)只要是手機，你就必須可以做到的。

下面是手機接口。

public interface Mobile {

    public void call();//手機可以打電話(huà)
    
    public void sendMessage();//手機可以發(fā)短信
    
    public void playBird();//手機可以玩憤怒的小鳥(niǎo)？
    
}

上面第三個(gè)行為明顯就不是一個(gè)手機必須有的，那么上面這個(gè)手機的接口就不是最小接口，假設我現在的非智能手機去實(shí)現這個(gè)接口，那么playBird方法就只能空著(zhù)了，因為它不能玩。

3、自己理解

這個(gè)沒(méi)啥說(shuō)的，很好理解，最上面我寫(xiě)單一職責原則的時(shí)候的那個(gè)案例，中間那部分就是接口隔離原則。這個(gè)思想自己要慢慢培養，然后更多的運用到實(shí)際開(kāi)發(fā)中去。

四、依賴(lài)倒置原則

1、定義

依賴(lài)倒置原則包含三個(gè)含義

1） 高層模塊不應該依賴(lài)低層模塊,兩者都應該依賴(lài)其抽象

2） 抽象不應該依賴(lài)細節

3）細節應該依賴(lài)抽象

2、案例說(shuō)明

大家都喜歡閱讀，閱讀文學(xué)經(jīng)典滋潤自己的內心心靈，下面是小明同學(xué)閱讀文學(xué)經(jīng)典的一個(gè)類(lèi)圖

文學(xué)經(jīng)典類(lèi)

//文學(xué)經(jīng)典類(lèi)
public class LiteraryClassic{
    //閱讀文學(xué)經(jīng)典
    public void read(){
       System.out.println("文學(xué)經(jīng)典閱讀，滋潤自己的內心心靈");
    }
}

小明類(lèi)

//小明類(lèi)
public class XiaoMing{
    //閱讀文學(xué)經(jīng)典
    public void read(LiteraryClassic literaryClassic){
        literaryClassic.read();
    }
}

場(chǎng)景類(lèi)

public class Client{
   public static void main(Strings[] args){
      XiaoMing xiaoming = new XiaoMing();
      LiteraryClassic literaryClassic = new LiteraryClassic();
      //小明閱讀文學(xué)經(jīng)典
      xiaoming.read(literaryClassic);
   }

}

看，我們的實(shí)現，小明同學(xué)可以閱讀文學(xué)經(jīng)典了。

小明同學(xué)看了一段文學(xué)經(jīng)典后，忽然他想看看看小說(shuō)來(lái)放松一下自己,我們實(shí)現一個(gè)小說(shuō)類(lèi)：

小說(shuō)類(lèi)

//小說(shuō)類(lèi)
public class Novel{
    //閱讀小說(shuō)
    public void read(){
       System.out.println("閱讀小說(shuō)，放松自己");
    }
}

現在我們再來(lái)看代碼，發(fā)現XiaoMing類(lèi)的read方法只與文學(xué)經(jīng)典LiteraryClassic類(lèi)是強依賴(lài)，緊耦合關(guān)系，小明同學(xué)竟然閱讀不了小說(shuō)類(lèi)。這與現實(shí)明顯的是不符合的，代碼設計的是有問(wèn)題的。那么問(wèn)題在那里呢？

我們看小明類(lèi)，此類(lèi)是一個(gè)高層模塊，并且是一個(gè)細節實(shí)現類(lèi)，此類(lèi)依賴(lài)的是一個(gè)文學(xué)經(jīng)典LiteraryClassic類(lèi)，而文學(xué)經(jīng)典LiteraryClassic類(lèi)也是一個(gè)細節實(shí)現類(lèi)。這是不是就與我們說(shuō)的依賴(lài)倒置原則相違背呢？

依賴(lài)倒置原則是說(shuō)我們的高層模塊，實(shí)現類(lèi)，細節類(lèi)都應該是依賴(lài)與抽象，依賴(lài)與接口和抽象類(lèi)。

為了解決小明同學(xué)閱讀小說(shuō)的問(wèn)題，我們根據依賴(lài)倒置原則先抽象一個(gè)閱讀者接口,下面是完整的uml類(lèi)圖：

IReader接口：

public interface IReader{
   //閱讀
   public void read(IRead read){
       read.read();
   }

}

再定義一個(gè)被閱讀的接口IRead

public interface IRead{
   //被閱讀
   public void read();
}

再定義文學(xué)經(jīng)典類(lèi)和小說(shuō)類(lèi)

文學(xué)經(jīng)典類(lèi)：

//文學(xué)經(jīng)典類(lèi)
public class LiteraryClassic implements IRead{
    //閱讀文學(xué)經(jīng)典
    public void read(){
       System.out.println("文學(xué)經(jīng)典閱讀，滋潤自己的內心心靈");
    }
}

小說(shuō)類(lèi)

//小說(shuō)類(lèi)
public class Novel implements IRead{
    //閱讀小說(shuō)
    public void read(){
       System.out.println("閱讀小說(shuō)，放松自己");
    }
}

再實(shí)現小明類(lèi)

//小明類(lèi)
public class XiaoMing implements IReader{
    //閱讀
    public void read(IRead read){
        read.read();
    }
}

然后，我們再讓小明分別閱讀文學(xué)經(jīng)典和小說(shuō)

public class Client{
   public static void main(Strings[] args){
      XiaoMing xiaoming = new XiaoMing();
      IRead literaryClassic = new LiteraryClassic();
      //小明閱讀文學(xué)經(jīng)典
      xiaoming.read(literaryClassic);

      IRead novel = new Novel();
      //小明閱讀小說(shuō)
      xiaoming.read(novel);
   }
}

至此，小明同學(xué)是可以閱讀文學(xué)經(jīng)典，又可以閱讀小說(shuō)了，目的達到了。

為什么依賴(lài)抽象的接口可以適應變化的需求？這就要從接口的本質(zhì)來(lái)說(shuō)，接口就是把一些公司的方法和屬性聲明，然后具體的業(yè)務(wù)邏輯是可以在實(shí)現接口的具體類(lèi)中實(shí)現的。所以我們當依賴(lài)

對象是接口時(shí)，就可以適應所有的實(shí)現此接口的具體類(lèi)變化。

3、依賴(lài)的三種方法

依賴(lài)是可以傳遞，A對象依賴(lài)B對象，B又依賴(lài)C，C又依賴(lài)D，……，依賴(lài)不止。只要做到抽象依賴(lài)，即使是多層的依賴(lài)傳遞也無(wú)所謂懼。

1）構造函數傳遞依賴(lài)對象

在類(lèi)中通過(guò)構造函數聲明依賴(lài)對象，按照依賴(lài)注入的說(shuō)法，這種方式叫做構造函數注入：

//小明類(lèi)
public class XiaoMing implements IReader{
     private IRead read;
     //構造函數注入
     public XiaoMing(IRead read){
        this.read = read;
     }

    //閱讀
    public void read(){
        read.read();
    }
}

2）Setter方法傳遞依賴(lài)對象

在類(lèi)中通過(guò)Setter方法聲明依賴(lài)關(guān)系，依照依賴(lài)注入的說(shuō)法，這是Setter依賴(lài)注入

//小明類(lèi)
public class XiaoMing implements IReader{
     private IRead read;
     //Setter依賴(lài)注入
     public setRead(IRead read){
        this.read = read;
     }

    //閱讀
    public void read(){
        read.read();
    }
}

3）接口聲明依賴(lài)

在接口的方法中聲明依賴(lài)對象，在為什么我們要符合依賴(lài)倒置原則的例子中，我們采用了接口聲明依賴(lài)的方式，該方法也叫做接口注入。

4、依賴(lài)倒置原則的經(jīng)驗

依賴(lài)倒置原則的本質(zhì)就是通過(guò)抽象(接口或抽象類(lèi))使各個(gè)類(lèi)或模塊的實(shí)現彼此獨立，不互相影響，實(shí)現模塊間的松耦合。我們在項目中使用這個(gè)原則要遵循下面的規則：

1）每個(gè)類(lèi)盡量都有接口或者抽象類(lèi)，或者抽象類(lèi)和接口兩都具備

2）變量的表面類(lèi)型盡量是接口或者抽象類(lèi)

3）任何類(lèi)都不應該從具體類(lèi)派生

4）盡量不要覆寫(xiě)基類(lèi)的方法

如果基類(lèi)是一個(gè)抽象類(lèi)，而這個(gè)方法已經(jīng)實(shí)現了，子類(lèi)盡量不要覆寫(xiě)。類(lèi)間依賴(lài)的是抽象，覆寫(xiě)了抽象方法，對依賴(lài)的穩定性會(huì )有一定的影響。

5）結合里氏替換原則使用

依賴(lài)倒置原則是6個(gè)設計原則中最難以實(shí)現的原則，它是實(shí)現開(kāi)閉原則的重要方法，在項目中，大家只要記住是”面向接口編程”就基本上是抓住了依賴(lài)倒置原則的核心了。

五、迪米特原則

這個(gè)原則在開(kāi)發(fā)中還是非常有用的。

1、定義

大致意思是：即一個(gè)類(lèi)應該盡量不要知道其他類(lèi)太多的東西，不要和陌生的類(lèi)有太多接觸。

迪米特原則還有一個(gè)解釋?zhuān)篛nly talk to your immediate friends（只與直接朋友通信）。

什么叫直接朋友呢？每個(gè)對象都必然會(huì )與其他對象有耦合關(guān)系，兩個(gè)對象之間的耦合就成為朋友關(guān)系，這種關(guān)系類(lèi)型有很多，例如：組合，聚合，依賴(lài)等。朋友類(lèi)也可以這樣定義：出現在成員

變量，方法的輸入輸出參數中的類(lèi)，稱(chēng)為朋友類(lèi)。

2、案例說(shuō)明

上體育課，我們經(jīng)常有這樣一個(gè)場(chǎng)景：

體育老師上課前要體育委員確認一下全班女生到了多少位，也就是體育委員清點(diǎn)女生的人數。如圖：

分析：這里其實(shí)體育老師和體育委員是朋友，因為他們是有業(yè)務(wù)來(lái)源，而女生人數是和體育委員有業(yè)務(wù)來(lái)源（它們是朋友），但是體育老師和女生人數是沒(méi)有直接業(yè)務(wù)來(lái)源的所以體育老師類(lèi)中

不應該參雜女生相關(guān)信息，這就是迪米特原則

(1)沒(méi)有才有迪米特原則

體育老師類(lèi)

public class Teacher{

  //老師對體育委員發(fā)一個(gè)命令，讓其清點(diǎn)女生人數的方法
  public void command(GroupLeader groupLeader){
     List<Girl> listGirls = new ArrayList();
     //初始化女生，發(fā)現老師和女生有耦合
     for(int i=0;i<20;i++){
       listGirls.add(new Girl());
     }
     //告訴體育委員開(kāi)始清點(diǎn)女生人數
     groupLeader.countGirls(listGirls);
  }
}

體育委員類(lèi)

public class GroupLeader{
  //清點(diǎn)女生數量
  public void countGirls(List<Girl> listGirls){
     System.out.println("女生人數是："+listGirls.size());
  }
}

女生類(lèi)

publci class Girl{
}

測試類(lèi)

public class Client{
   public static void main(Strings[] args){
      Teacher teacher = new Teacher();
      //老師給體育委員發(fā)清點(diǎn)女生人數的命令
      teacher.command(new GroupLeader());
   }
}

分析：我們再回頭看Teacher類(lèi)，Teacher類(lèi)只有一個(gè)朋友類(lèi)GroupLeader，Girl類(lèi)不是朋友類(lèi)，但是Teacher與Girl類(lèi)通信了，這就破壞了Teacher類(lèi)的健壯性，Teacher類(lèi)的方法竟然與一個(gè)不是

自己的朋友類(lèi)Girl類(lèi)通信，這是不允許的，嚴重違反了迪米特原則。

(2)采用迪米特原則

我們對程序進(jìn)行如下修改，將類(lèi)圖修改如下：

修改后的老師類(lèi)：（注意這里面已經(jīng)沒(méi)有女生信息了）

public class Teacher{
  //老師對體育委員發(fā)一個(gè)命令，讓其清點(diǎn)女生人數
  public void command(GroupLeader groupLeader){
     //告訴體育委員開(kāi)始清點(diǎn)女生人數
     groupLeader.countGirls();
  }
} 

修改后的體育委員類(lèi)

public class GroupLeader{
   private List<Girl> listGirls;
   public GroupLeader(List<Girl> listGirls){
      this.listGirls = listGirls;
   }
  //清點(diǎn)女生數量
  public void countGirls(){
     System.out.println("女生人數是："+listGirls.size());
  }
}

修改后的測試類(lèi)

public class Client{
   public static void main(Strings[] args){
     //產(chǎn)生女生群體
     List<Girl> listGirls = new ArrayList<Girl>();
     //初始化女生
     for(int i=0;i<20;i++){
       listGirls.add(new Girl());
     }

      Teacher teacher = new Teacher();
      //老師給體育委員發(fā)清點(diǎn)女生人數的命令
      teacher.command(new GroupLeader(listGirls));
   }
}

對程序修改，把Teacher中對Girl群體的初始化移動(dòng)到場(chǎng)景類(lèi)中，同時(shí)在GroupLeader中增加對Girl的注入，避開(kāi)了Teacher類(lèi)對陌生類(lèi)Girl的訪(fǎng)問(wèn)，降低了系統間的耦合，提高了系統的健壯性。

在實(shí)踐中經(jīng)常出現這樣一個(gè)方法，放在本類(lèi)中也可以，放到其它類(lèi)中也可以。那怎么處理呢？你可以堅持一個(gè)原則：如果一個(gè)方法放在本類(lèi)中，即不增加類(lèi)間關(guān)系，也對本類(lèi)不產(chǎn)生負面影響，那就放到本類(lèi)中。

迪米特原則的核心觀(guān)念就是類(lèi)間解耦，弱耦合，只有弱耦合后，類(lèi)的復用率才可以提高。其結果就是產(chǎn)生了大量的中轉或跳轉類(lèi)，導致系統復雜，為維護帶來(lái)了難度。所以，我們在實(shí)踐時(shí)要反

復權衡，即要讓結構清晰，又做到高內聚低耦合。

3、自己理解

迪米特原則在自己開(kāi)發(fā)中一定要培養這種思想，因為它沒(méi)有那么模糊，而且這個(gè)原則沒(méi)啥爭議。

六、開(kāi)閉原則

這個(gè)原則更像是前五個(gè)原則的總綱，前五個(gè)原則就是圍著(zhù)它轉的，只要我們盡量的遵守前五個(gè)原則，那么設計出來(lái)的系統應該就比較符合開(kāi)閉原則了，相反，如果你違背了太多，那么你的系統或許也不太遵循開(kāi)閉原則。

1、定義

一句話(huà)，對修改關(guān)閉，對擴展開(kāi)放。

就是說(shuō)我任何的改變都不需要修改原有的代碼，而只需要加入一些新的實(shí)現，就可以達到我的目的，這是系統設計的理想境界，但是沒(méi)有任何一個(gè)系統可以做到這一點(diǎn)，哪怕我一直最欣賞的

spring框架也做不到，雖說(shuō)它的擴展性已經(jīng)強到變態(tài)。這個(gè)就不說(shuō)了，字面上也能理解個(gè)八九分，它對我來(lái)講太抽象。雖然它很重要。

總結

如果你理解會(huì )運用了這六大原則，那么你寫(xiě)出的代碼一定是非常漂亮的，二不是那么臃腫，遍地第都是垃圾代碼了。

以上就是詳解java設計模式之六大原則的詳細內容，更多關(guān)于java設計模式之六大原則的資料請關(guān)注腳本之家其它相關(guān)文章！