一、單一職責(zé)原則

1、單一職責(zé)定義

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

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

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

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

1）降低了類的復(fù)雜度。一個(gè)類只負(fù)責(zé)一項(xiàng)職責(zé)比負(fù)責(zé)多項(xiàng)職責(zé)要簡(jiǎn)單得多。

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

3) 提高了系統(tǒng)的可維護(hù)性。代碼的可讀性高了，并且修改一項(xiàng)職責(zé)對(duì)其他職責(zé)影響降低了，可維護(hù)性自然就提高了。

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

3、案例說(shuō)明

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

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

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

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

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

代碼清單1-1 分清職責(zé)后的代碼示例

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

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

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

4、自己理解

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

1) 職責(zé)劃分：

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

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

2）類的冗余

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

我自己的感悟：

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

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

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

二、里氏代換原則

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

1、定義

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

簡(jiǎn)單理解就是：子類一般不該重寫父類的方法，因?yàn)楦割惖姆椒ㄒ话愣际菍?duì)外公布的接口，是具有不可變性的，你不該將一些不該變化的東西給修改掉。

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

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

繼承的弊端：

繼承作為面向?qū)ο笕筇匦灾?，在給程序設(shè)計(jì)帶來(lái)巨大便利的同時(shí)，也帶來(lái)了弊端。

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

2、案例說(shuō)明

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

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

父類代碼

public class Parent {

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

SubClass子類把父類的方法給覆蓋。

public class SubClass extends Parent{

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

測(cè)試類

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

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

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

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

3、自己理解

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

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

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

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

三、接口隔離原則

1、定義

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

為什么要這么做呢？

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

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

2、案例說(shuō)明

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

下面是手機(jī)接口。

public interface Mobile {

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

上面第三個(gè)行為明顯就不是一個(gè)手機(jī)必須有的，那么上面這個(gè)手機(jī)的接口就不是最小接口，假設(shè)我現(xiàn)在的非智能手機(jī)去實(shí)現(xiàn)這個(gè)接口，那么playBird方法就只能空著了，因?yàn)樗荒芡妗?/p>

3、自己理解

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

四、依賴倒置原則

1、定義

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

1） 高層模塊不應(yīng)該依賴低層模塊,兩者都應(yīng)該依賴其抽象

2） 抽象不應(yīng)該依賴細(xì)節(jié)

3）細(xì)節(jié)應(yīng)該依賴抽象

2、案例說(shuō)明

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

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

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

小明類

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

場(chǎng)景類

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

}

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

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

小說(shuō)類

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

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

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

依賴倒置原則是說(shuō)我們的高層模塊，實(shí)現(xiàn)類，細(xì)節(jié)類都應(yīng)該是依賴與抽象，依賴與接口和抽象類。

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

IReader接口：

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

}

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

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

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

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

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

小說(shuō)類

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

再實(shí)現(xiàn)小明類

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

然后，我們?cè)僮屝∶鞣謩e閱讀文學(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ō)了，目的達(dá)到了。

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

對(duì)象是接口時(shí)，就可以適應(yīng)所有的實(shí)現(xiàn)此接口的具體類變化。

3、依賴的三種方法

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

1）構(gòu)造函數(shù)傳遞依賴對(duì)象

在類中通過(guò)構(gòu)造函數(shù)聲明依賴對(duì)象，按照依賴注入的說(shuō)法，這種方式叫做構(gòu)造函數(shù)注入：

//小明類
public class XiaoMing implements IReader{
     private IRead read;
     //構(gòu)造函數(shù)注入
     public XiaoMing(IRead read){
        this.read = read;
     }

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

2）Setter方法傳遞依賴對(duì)象

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

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

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

3）接口聲明依賴

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

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

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

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

2）變量的表面類型盡量是接口或者抽象類

3）任何類都不應(yīng)該從具體類派生

4）盡量不要覆寫基類的方法

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

5）結(jié)合里氏替換原則使用

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

五、迪米特原則

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

1、定義

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

迪米特原則還有一個(gè)解釋：Only talk to your immediate friends（只與直接朋友通信）。

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

變量，方法的輸入輸出參數(shù)中的類，稱為朋友類。

2、案例說(shuō)明

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

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

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

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

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

體育老師類

public class Teacher{

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

體育委員類

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

女生類

publci class Girl{
}

測(cè)試類

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

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

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

(2)采用迪米特原則

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

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

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

修改后的體育委員類

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

修改后的測(cè)試類

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)女生人數(shù)的命令
      teacher.command(new GroupLeader(listGirls));
   }
}

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

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

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

復(fù)權(quán)衡，即要讓結(jié)構(gòu)清晰，又做到高內(nèi)聚低耦合。

3、自己理解

迪米特原則在自己開(kāi)發(fā)中一定要培養(yǎng)這種思想，因?yàn)樗鼪](méi)有那么模糊，而且這個(gè)原則沒(méi)啥爭(zhēng)議。

六、開(kāi)閉原則

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

1、定義

一句話，對(duì)修改關(guān)閉，對(duì)擴(kuò)展開(kāi)放。

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

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

總結(jié)

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

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

最新評(píng)論