一、單一職責(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é)過多，就相當(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é)要簡單得多。

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

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

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

3、案例說明

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

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

這個(gè)接口是可以優(yōu)化的，用戶的屬性（Property）和用戶的行為（Behavior）沒有分開，這是一個(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é)用戶的屬性，簡單地說，IUserBO的職責(zé)就是收集和反饋用戶的屬性信息；IUserBiz負(fù)責(zé)用戶的行為，完成用戶信息的維護(hù)和變更。

然后IUserInfo來實(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ū)別呢，這里只能說實(shí)現(xiàn)了接口隔離原則（下面會(huì)說）

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

4、自己理解

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

1) 職責(zé)劃分：

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

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

2）類的冗余

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

我自己的感悟：

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

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

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

二、里氏代換原則

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

1、定義

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

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

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

怎么說呢，里氏代換原則的主要目的主要是防止繼承所帶來的弊端。

繼承的弊端：

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

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

2、案例說明

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è)子類重寫了父類的方法，說不支持該操作了 public void method() {throw new UnsupportedOperationException(); } }

測(cè)試類

/**這個(gè)異常是運(yùn)行時(shí)才會(huì)產(chǎn)生的，也就是說，我的SomeoneClass并不知道會(huì)出現(xiàn)這種情況，結(jié)果就是我調(diào)用下面這段代碼的時(shí)候， *本來我們的思維是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)楸緛砦覀兊脑瓌t是，父類可以完成的地方，我用子類替代是絕對(duì)沒有問題的，但是這下反了，我每次使用一個(gè)子類替換一個(gè)父類的時(shí)候，我還要擔(dān)心這個(gè)

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

3、自己理解

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

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

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

所以總的來說，要知道繼承的這個(gè)隱患，在開發(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)本來不該實(shí)現(xiàn)的方法，最嚴(yán)重的是會(huì)給使用者造成假象，即這個(gè)實(shí)現(xiàn)類擁有接口中所有的行為，結(jié)果調(diào)用方法時(shí)卻沒收獲到想要的結(jié)果。

2、案例說明

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

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

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

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

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

四、依賴倒置原則1、定義

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

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

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

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

2、案例說明

大家都喜歡閱讀，閱讀文學(xué)經(jīng)典滋潤自己的內(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)典閱讀，滋潤自己的內(nèi)心心靈'); }}

小明類

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

場景類

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)典后，忽然他想看看看小說來放松一下自己,我們實(shí)現(xiàn)一個(gè)小說類：

小說類

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

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

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

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

為了解決小明同學(xué)閱讀小說的問題，我們根據(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)典類和小說類

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

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

小說類

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

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

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

然后，我們?cè)僮屝∶鞣謩e閱讀文學(xué)經(jīng)典和小說

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(); //小明閱讀小說 xiaoming.read(novel); }}

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

為什么依賴抽象的接口可以適應(yīng)變化的需求？這就要從接口的本質(zhì)來說，接口就是把一些公司的方法和屬性聲明，然后具體的業(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，……，依賴不止。只要做到抽象依賴，即使是多層的依賴傳遞也無所謂懼。

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

在類中通過構(gòu)造函數(shù)聲明依賴對(duì)象，按照依賴注入的說法，這種方式叫做構(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ì)象

在類中通過Setter方法聲明依賴關(guān)系，依照依賴注入的說法，這是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ì)就是通過抽象(接口或抽象類)使各個(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)開閉原則的重要方法，在項(xiàng)目中，大家只要記住是”面向接口編程”就基本上是抓住了依賴倒置原則的核心了。

五、迪米特原則

這個(gè)原則在開發(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、案例說明

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

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

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

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

(1)沒有才有迪米特原則

體育老師類

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()); } //告訴體育委員開始清點(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)沒有女生信息了）

public class Teacher{ //老師對(duì)體育委員發(fā)一個(gè)命令，讓其清點(diǎn)女生人數(shù) public void command(GroupLeader groupLeader){ //告訴體育委員開始清點(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)到場景類中，同時(shí)在GroupLeader中增加對(duì)Girl的注入，避開了Teacher類對(duì)陌生類Girl的訪問，降低了系統(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ù)帶來了難度。所以，我們?cè)趯?shí)踐時(shí)要反

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

3、自己理解

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

六、開閉原則

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

1、定義

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

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

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

總結(jié)

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

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