其他同系列的文章還有：
面向?qū)ο缶幊讨械牧笤瓌t
設(shè)計(jì)模式| 創(chuàng)建型模式
設(shè)計(jì)模式| 結(jié)構(gòu)型模式
設(shè)計(jì)模式| 行為型模式 (上)
設(shè)計(jì)模式| 行為型模式 (下)
歡迎閱讀旺拉，評(píng)論！Ｂ来毅否！

前言

從面向過程到面向?qū)ο笫擒浖O(shè)計(jì)誕生以來的邁出的最偉大的一步，
使用面向?qū)ο笤O(shè)計(jì)，可以設(shè)計(jì)出優(yōu)秀的軟件树枫，同樣也可以設(shè)計(jì)出糟糕的軟件直焙。
只有遵循一些特定的原則，才能設(shè)計(jì)出復(fù)用性高靈活性好的軟件來砂轻。

在運(yùn)用面向?qū)ο蟮乃枷脒M(jìn)行軟件設(shè)計(jì)時(shí)奔誓，需要遵循的原則一共有6個(gè)，他們是：

1. 單一職責(zé)原則（Single Responsibility Principle）
2. 里氏替換原則（Liskov Substitution Principle）
3. 依賴倒置原則（Dependence Inversion Principle）
4. 接口隔離原則（Interface Segregation Principle）
5. 迪米特法則（Law Of Demeter）
6. 開閉原則（Open Close Principle）

在軟件設(shè)計(jì)的過程中搔涝，只要我們盡量遵循以上六條設(shè)計(jì)原則厨喂，
設(shè)計(jì)出來的軟件一定會(huì)是一個(gè)優(yōu)秀的軟件，它必定足夠健壯体谒、足夠穩(wěn)定杯聚，并以極大的靈活性來迎接隨時(shí)而來的需求變更等因素。
當(dāng)完全明白這六個(gè)原則的含義時(shí)抒痒，小菜便完成了走向大牛的蛻變幌绍。

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

即一個(gè)類只負(fù)責(zé)一項(xiàng)職責(zé)故响。

問題由來：

類T負(fù)責(zé)兩個(gè)不同的職責(zé)：職責(zé)P1傀广，職責(zé)P2。當(dāng)由于職責(zé)P1需求發(fā)生改變而需要修改類T時(shí)彩届，
有可能會(huì)導(dǎo)致原本運(yùn)行正常的職責(zé)P2功能發(fā)生故障伪冰。

解決方案：

遵循單一職責(zé)原則。分別建立兩個(gè)類T1樟蠕、T2贮聂，使T1完成職責(zé)P1功能，T2完成職責(zé)P2功能寨辩。
這樣吓懈，當(dāng)修改類T1時(shí)，不會(huì)使職責(zé)P2發(fā)生故障風(fēng)險(xiǎn)靡狞；同理耻警，當(dāng)修改T2時(shí)，也不會(huì)使職責(zé)P1發(fā)生故障風(fēng)險(xiǎn)甸怕。

說到單一職責(zé)原則甘穿，很多人都會(huì)不屑一顧。因?yàn)樗唵瘟松液肌Ｉ杂薪?jīng)驗(yàn)的程序員即使從來沒有讀過設(shè)計(jì)模式温兼、從來沒有聽說過單一職責(zé)原則
在設(shè)計(jì)軟件時(shí)也會(huì)自覺的遵守這一重要原則，因?yàn)檫@是常識(shí)武契。在軟件編程中募判，誰也不希望因?yàn)樾薷牧艘粋€(gè)功能導(dǎo)致其他的功能發(fā)生故障缸榛。
而避免出現(xiàn)這一問題的方法便是遵循單一職責(zé)原則。

雖然單一職責(zé)原則如此簡單兰伤，并且被認(rèn)為是常識(shí)，但是即便是經(jīng)驗(yàn)豐富的程序員寫出的程序钧排，也會(huì)有違背這一原則的代碼存在敦腔。
為什么會(huì)出現(xiàn)這種現(xiàn)象呢？

因?yàn)橛?strong>職責(zé)擴(kuò)散恨溜。所謂職責(zé)擴(kuò)散符衔，就是因?yàn)槟撤N原因，職責(zé)P被分化為粒度更細(xì)的職責(zé)P1和P2糟袁。這是實(shí)際情況中非常容易出現(xiàn)的現(xiàn)象判族。

有一種方式?jīng)]有改動(dòng)原來的方法，而是在類中新加了一個(gè)方法项戴，這樣雖然也違背了單一職責(zé)原則形帮，但在方法級(jí)別上卻是符合單一職責(zé)原則的，因?yàn)樗]有動(dòng)原來方法的代碼周叮。

我的原則是：只有邏輯足夠簡單辩撑，才可以在代碼級(jí)別上違反單一職責(zé)原則；只有類中方法數(shù)量足夠少仿耽，才可以在方法級(jí)別上違反單一職責(zé)原則合冀；否則立即重構(gòu)出新的類。

遵循（類项贺、方法）單一職責(zé)原的優(yōu)點(diǎn)有：

- 可以降低類的復(fù)雜度君躺，一個(gè)類只負(fù)責(zé)一項(xiàng)職責(zé)，其邏輯肯定要比負(fù)責(zé)多項(xiàng)職責(zé)簡單的多开缎；
- 提高類的可讀性棕叫，提高系統(tǒng)的可維護(hù)性；
- 變更引起的風(fēng)險(xiǎn)降低啥箭，變更是必然的谍珊，如果單一職責(zé)原則遵守的好，當(dāng)修改一個(gè)功能時(shí)急侥，可以顯著降低對(duì)其他功能的影響砌滞。

2、里氏替換原則

問題由來：
有一功能P1坏怪，由類A完成”慈螅現(xiàn)需要將功能P1進(jìn)行擴(kuò)展，擴(kuò)展后的功能為P铝宵，其中P由原有功能P1與新功能P2組成打掘。
新功能P由類A的子類B來完成华畏，則子類B在完成新功能P2的同時(shí)，有可能會(huì)導(dǎo)致原有功能P1發(fā)生故障尊蚁。

解決方案：
當(dāng)使用繼承時(shí)亡笑，遵循里氏替換原則。類B繼承類A時(shí)横朋，除添加新的方法完成新增功能P2外仑乌，
盡量不要重寫父類A的方法，也盡量不要重載父類A的方法琴锭。


里氏替換原則就是依賴于繼承和多態(tài)兩大特性晰甚。
簡單地說，就是父類能出現(xiàn)的地方子類就可以出現(xiàn)决帖，
而且替換成子類也不會(huì)出現(xiàn)任何錯(cuò)誤或者異常厕九，
而使用者也無需知道是父類還是子類。
但是有子類的地方不一定適用于所有父類地回。

里氏替換原則通俗的來講就是：子類可以擴(kuò)展父類的功能扁远，但不能改變父類原有的功能。

它包含以下4層含義：

 - 子類可以實(shí)現(xiàn)父類的抽象方法落君，但不能覆蓋父類的非抽象方法穿香。
 - 子類中可以增加自己特有的方法。
 - 當(dāng)子類的方法重載父類的方法時(shí)绎速，方法的前置條件（即方法的形參）要比父類方法的輸入?yún)?shù)更寬松皮获。
 - 當(dāng)子類的方法實(shí)現(xiàn)父類的抽象方法時(shí)，方法的后置條件（即方法的返回值）要比父類更嚴(yán)格纹冤。
    

`重載（overload）：函數(shù)名相同,函數(shù)的參數(shù)列表不同(包括參數(shù)個(gè)數(shù)和參數(shù)類型)洒宝，
至于返回類型可同可不同。重載既可以發(fā)生在同一個(gè)類的不同函數(shù)之間萌京，也可發(fā)生在父類子類的繼承關(guān)系之間雁歌，
其中發(fā)生在父類子類之間時(shí)要注意與重寫區(qū)分開。`

`重寫（override）：發(fā)生于父類和子類之間知残，指的是子類不想繼承使用父類的方法靠瞎，
通過重寫同一個(gè)函數(shù)的實(shí)現(xiàn)實(shí)現(xiàn)對(duì)父類中同一個(gè)函數(shù)的覆蓋，因此又叫函數(shù)覆蓋求妹。
注意重寫的函數(shù)必須和父類一模一樣乏盐，包括函數(shù)名、參數(shù)個(gè)數(shù)和類型以及返回值制恍，只是重寫了函數(shù)的實(shí)現(xiàn)父能，這也是和重載區(qū)分開的關(guān)鍵。`

看上去很不可思議净神，因?yàn)槲覀儠?huì)發(fā)現(xiàn)在自己編程中常常會(huì)違反里氏替換原則何吝，程序照樣跑的好好的溉委。
所以大家都會(huì)產(chǎn)生這樣的疑問，假如我非要不遵循里氏替換原則會(huì)有什么后果爱榕？

后果就是：你寫的代碼出問題的幾率將會(huì)大大增加瓣喊。

3、依賴倒置原則

定義：高層模塊不應(yīng)該依賴低層模塊黔酥，二者都應(yīng)該依賴其抽象型宝；抽象不應(yīng)該依賴細(xì)節(jié)；細(xì)節(jié)應(yīng)該依賴抽象絮爷。

問題由來：類A直接依賴類B，假如要將類A改為依賴類C梨树，則必須通過修改類A的代碼來達(dá)成坑夯。    
這種場景下，類A一般是高層模塊抡四，負(fù)責(zé)復(fù)雜的業(yè)務(wù)邏輯柜蜈；類B和類C是低層模塊，
負(fù)責(zé)基本的原子操作指巡；假如修改類A淑履，會(huì)給程序帶來不必要的風(fēng)險(xiǎn)。

解決方案：將類A修改為依賴接口I藻雪，類B和類C各自實(shí)現(xiàn)接口I秘噪，
類A通過接口I間接與類B或者類C發(fā)生聯(lián)系，則會(huì)大大降低修改類A的幾率勉耀。

依賴倒置原則基于這樣一個(gè)事實(shí)：相對(duì)于細(xì)節(jié)的多變性指煎，抽象的東西要穩(wěn)定的多。
以抽象為基礎(chǔ)搭建起來的架構(gòu)比以細(xì)節(jié)為基礎(chǔ)搭建起來的架構(gòu)要穩(wěn)定的多便斥。
在java中至壤，抽象指的是接口或者抽象類，細(xì)節(jié)就是具體的實(shí)現(xiàn)類枢纠，使用接口或者抽象類的目的是制定好規(guī)范和契約像街，
而不去涉及任何具體的操作，把展現(xiàn)細(xì)節(jié)的任務(wù)交給他們的實(shí)現(xiàn)類去完成晋渺。

依賴倒置原則的核心思想是面向接口編程镰绎。

class Newspaper implements IReader {
    public String getContent(){
        return "林書豪17+9助尼克斯擊敗老鷹……";
    }
}
class Book implements IReader{
    public String getContent(){
        return "很久很久以前有一個(gè)阿拉伯的故事……";
    }
}

class Mother{
    public void narrate(IReader reader){
        System.out.println("媽媽開始講故事");
        System.out.println(reader.getContent());
    }
}

public class Client{
    public static void main(String[] args){
        Mother mother = new Mother();
        mother.narrate(new Book());
        mother.narrate(new Newspaper());
    }
}

這樣設(shè)計(jì)后，無論以后怎樣擴(kuò)展Client類些举，都不需要再修改Mother類了跟狱，這只是一個(gè)簡單的例子，實(shí)際情況中户魏，
代表高層模塊的Mother類將負(fù)責(zé)完成主要的業(yè)務(wù)邏輯予跌，一旦需要對(duì)它進(jìn)行修改葛躏，引入錯(cuò)誤的風(fēng)險(xiǎn)極大烤礁。
所以遵循依賴倒置原則可以降低類之間的耦合性，提高系統(tǒng)的穩(wěn)定性扛门，降低修改程序造成的風(fēng)險(xiǎn)。

 依賴倒置原則的核心就是要我們面向接口編程纵寝，理解了面向接口編程论寨，也就理解了依賴倒置。

 采用依賴倒置原則給多人并行開發(fā)帶來了極大的便利爽茴，比如上例中葬凳，原本Mother類與Book類直接耦合時(shí)，
 Mother類必須等Book類編碼完成后才可以進(jìn)行編碼室奏，因?yàn)镸other類依賴于Book類火焰。
 修改后的程序則可以同時(shí)開工，互不影響胧沫，因?yàn)镸other與Book類一點(diǎn)關(guān)系也沒有昌简。
 參與協(xié)作開發(fā)的人越多、項(xiàng)目越龐大绒怨，采用依賴導(dǎo)致原則的意義就越重大纯赎。
 依賴倒置原則的核心就是要我們面向接口編程，理解了面向接口編程南蹂，也就理解了依賴倒置犬金。

4、 接口隔離原則

定義：客戶端不應(yīng)該依賴它不需要的接口六剥；一個(gè)類對(duì)另一個(gè)類的依賴應(yīng)該建立在最小的接口上佑附。

問題由來：類A通過接口I依賴類B，類C通過接口I依賴類D仗考，如果接口I對(duì)于類A和類B來說不是最小接口音同，
        則類B和類D必須去實(shí)現(xiàn)他們不需要的方法。

解決方案：將臃腫的接口I拆分為獨(dú)立的幾個(gè)接口秃嗜，類A和類C分別與他們需要的接口建立依賴關(guān)系权均。也就是采用接口隔離原則。

一個(gè)接口代表一個(gè)角色锅锨，不應(yīng)當(dāng)將不同的角色都交給一個(gè)接口叽赊。
沒有關(guān)系的接口合并在一起，形成一個(gè)臃腫的大接口必搞，這是對(duì)角色和接口的污染必指。

“不應(yīng)該強(qiáng)迫客戶依賴于它們不用的方法。接口屬于客戶恕洲，不屬于它所在的類層次結(jié)構(gòu)”這個(gè)說得很明白了塔橡，
再通俗點(diǎn)說梅割，不要強(qiáng)迫客戶使用它們不用的方法，如果強(qiáng)迫用戶使用它們不使用的方法葛家，

那么這些客戶就會(huì)面臨由于這些不使用的方法的改變所帶來的改變户辞。

接口隔離原則的含義是：建立單一接口，不要建立龐大臃腫的接口癞谒，盡量細(xì)化接口底燎，接口中的方法盡量少。
也就是說弹砚，我們要為各個(gè)類建立專用的接口双仍，而不要試圖去建立一個(gè)很龐大的接口供所有依賴它的類去調(diào)用。

采用接口隔離原則對(duì)接口進(jìn)行約束時(shí)桌吃，要注意以下幾點(diǎn)：

1.接口盡量小殊校，但是要有限度。對(duì)接口進(jìn)行細(xì)化可以提高程序設(shè)計(jì)靈活性是不掙的事實(shí)读存，
  但是如果過小，則會(huì)造成接口數(shù)量過多呕屎，使設(shè)計(jì)復(fù)雜化让簿。所以一定要適度。

2. 為依賴接口的類定制服務(wù)秀睛，只暴露給調(diào)用的類它需要的方法尔当，它不需要的方法則隱藏起來。
  只有專注地為一個(gè)模塊提供定制服務(wù)蹂安，才能建立最小的依賴關(guān)系椭迎。

3.提高內(nèi)聚，減少對(duì)外交互田盈。使接口用最少的方法去完成最多的事情畜号。
  運(yùn)用接口隔離原則，一定要適度允瞧，接口設(shè)計(jì)的過大或過小都不好简软。
  設(shè)計(jì)接口的時(shí)候，只有多花些時(shí)間去思考和籌劃述暂，才能準(zhǔn)確地實(shí)踐這一原則痹升。

這樣就能很好的滿足接口隔離原則了,調(diào)用者只能訪問它自己的方法,不能訪問到不應(yīng)該訪問的方法.

5、 迪米特法則

定義：一個(gè)對(duì)象應(yīng)該對(duì)其他對(duì)象保持最少的了解畦韭。

問題由來：類與類之間的關(guān)系越密切疼蛾，耦合度越大，當(dāng)一個(gè)類發(fā)生改變時(shí)艺配，對(duì)另一個(gè)類的影響也越大察郁。

解決方案：盡量降低類與類之間的耦合衍慎。

自從我們接觸編程開始，就知道了軟件編程的總的原則：低耦合绳锅，高內(nèi)聚西饵。
無論是面向過程編程還是面向?qū)ο缶幊蹋挥惺垢鱾€(gè)模塊之間的耦合盡量的低鳞芙，才能提高代碼的復(fù)用率眷柔。
低耦合的優(yōu)點(diǎn)不言而喻，但是怎么樣編程才能做到低耦合呢原朝？那正是迪米特法則要去完成的驯嘱。

迪米特法則又叫最少知道原則，最早是在1987年由美國Northeastern University的Ian Holland提出喳坠。通俗的來講鞠评，就是一個(gè)類對(duì)自己依賴的類知道的越少越好。也就是說壕鹉，對(duì)于被依賴的類來說剃幌，無論邏輯多么復(fù)雜，都盡量地的將邏輯封裝在類的內(nèi)部晾浴，對(duì)外除了提供的public方法负乡，不對(duì)外泄漏任何信息。

迪米特法則還有一個(gè)更簡單的定義：只與直接的朋友通信脊凰。

首先來解釋一下什么是直接的朋友：每個(gè)對(duì)象都會(huì)與其他對(duì)象有耦合關(guān)系抖棘，
只要兩個(gè)對(duì)象之間有耦合關(guān)系，我們就說這兩個(gè)對(duì)象之間是朋友關(guān)系狸涌。耦合的方式很多切省，依賴、關(guān)聯(lián)帕胆、組合朝捆、聚合等。
其中懒豹，我們稱出現(xiàn)成員變量右蹦、方法參數(shù)、方法返回值中的類為直接的朋友歼捐，而出現(xiàn)在局部變量中的類則不是直接的朋友何陆。
也就是說，陌生的類最好不要作為局部變量的形式出現(xiàn)在類的內(nèi)部豹储。

值得注意的是：

    迪米特法則的初衷是降低類之間的耦合贷盲，由于每個(gè)類都減少了不必要的依賴，因此的確可以降低耦合關(guān)系。
    但是凡事都有度巩剖，雖然可以避免與非直接的類通信铝穷，但是要通信，必然會(huì)通過一個(gè)“中介”來發(fā)生聯(lián)系佳魔，
    例如例中曙聂，總公司就是通過分公司這個(gè)“中介”來與分公司的員工發(fā)生聯(lián)系的。過分的使用迪米特原則鞠鲜，
    會(huì)產(chǎn)生大量這樣的中介和傳遞類宁脊，導(dǎo)致系統(tǒng)復(fù)雜度變大。所以在采用迪米特法則時(shí)要反復(fù)權(quán)衡贤姆，既做到結(jié)構(gòu)清晰榆苞，又要高內(nèi)聚低耦合。

6.霞捡、開閉原則

定義：一個(gè)軟件實(shí)體如類坐漏、模塊和函數(shù)應(yīng)該對(duì)擴(kuò)展開放，對(duì)修改關(guān)閉碧信。

問題由來：在軟件的生命周期內(nèi)赊琳，因?yàn)樽兓⑸?jí)和維護(hù)等原因需要對(duì)軟件原有代碼進(jìn)行修改時(shí)砰碴，可能會(huì)給舊代碼中引入錯(cuò)誤躏筏，
也可能會(huì)使我們不得不對(duì)整個(gè)功能進(jìn)行重構(gòu)，并且需要原有代碼經(jīng)過重新測試衣式。

解決方案：當(dāng)軟件需要變化時(shí)，盡量通過擴(kuò)展軟件實(shí)體的行為來實(shí)現(xiàn)變化檐什，而不是通過修改已有的代碼來實(shí)現(xiàn)變化碴卧。

開閉原則是面向?qū)ο笤O(shè)計(jì)中最基礎(chǔ)的設(shè)計(jì)原則，它指導(dǎo)我們?nèi)绾谓⒎€(wěn)定靈活的系統(tǒng)乃正。開閉原則可能是設(shè)計(jì)模式六項(xiàng)原則中定義最模糊的一個(gè)了住册，
它只告訴我們對(duì)擴(kuò)展開放，對(duì)修改關(guān)閉瓮具，可是到底如何才能做到對(duì)擴(kuò)展開放荧飞，對(duì)修改關(guān)閉，并沒有明確的告訴我們名党。
以前叹阔，如果有人告訴我“你進(jìn)行設(shè)計(jì)的時(shí)候一定要遵守開閉原則”，我會(huì)覺的他什么都沒說传睹，但貌似又什么都說了耳幢。因?yàn)殚_閉原則真的太虛了。

在仔細(xì)思考以及仔細(xì)閱讀很多設(shè)計(jì)模式的文章后，終于對(duì)開閉原則有了一點(diǎn)認(rèn)識(shí)睛藻。其實(shí)启上，我們遵循設(shè)計(jì)模式前面5大原則，
以及使用23種設(shè)計(jì)模式的目的就是遵循開閉原則店印。也就是說冈在，只要我們對(duì)前面5項(xiàng)原則遵守的好了，設(shè)計(jì)出的軟件自然是符合開閉原則的按摘，
這個(gè)開閉原則更像是前面五項(xiàng)原則遵守程度的“平均得分”包券，前面5項(xiàng)原則遵守的好，平均分自然就高院峡，說明軟件設(shè)計(jì)開閉原則遵守的好兴使；
如果前面5項(xiàng)原則遵守的不好，則說明開閉原則遵守的不好照激。

其實(shí)筆者認(rèn)為发魄，開閉原則無非就是想表達(dá)這樣一層意思：用抽象構(gòu)建框架，用實(shí)現(xiàn)擴(kuò)展細(xì)節(jié)俩垃。

因?yàn)槌橄箪`活性好励幼，適應(yīng)性廣，只要抽象的合理口柳，可以基本保持軟件架構(gòu)的穩(wěn)定苹粟。而軟件中易變的細(xì)節(jié)，
我們用從抽象派生的實(shí)現(xiàn)類來進(jìn)行擴(kuò)展跃闹，當(dāng)軟件需要發(fā)生變化時(shí)嵌削，我們只需要根據(jù)需求重新派生一個(gè)實(shí)現(xiàn)類來擴(kuò)展就可以了。
當(dāng)然前提是我們的抽象要合理望艺，要對(duì)需求的變更有前瞻性和預(yù)見性才行苛秕。

六大原則總結(jié)

說到這里，再回想一下前面說的5項(xiàng)原則找默，恰恰是告訴我們用抽象構(gòu)建框架艇劫，用實(shí)現(xiàn)擴(kuò)展細(xì)節(jié)的注意事項(xiàng)而已：
單一職責(zé)原則告訴我們實(shí)現(xiàn)類要職責(zé)單一；
里氏替換原則告訴我們不要破壞繼承體系惩激；
依賴倒置原則告訴我們要面向接口編程店煞；
接口隔離原則告訴我們?cè)谠O(shè)計(jì)接口的時(shí)候要精簡單一；
迪米特法則告訴我們要降低耦合风钻。
而開閉原則是總綱顷蟀，他告訴我們要對(duì)擴(kuò)展開放，對(duì)修改關(guān)閉骡技。

 最后說明一下如何去遵守這六個(gè)原則衩椒。對(duì)這六個(gè)原則的遵守并不是是和否的問題，而是多和少的問題，
也就是說毛萌，我們一般不會(huì)說有沒有遵守苟弛，而是說遵守程度的多少。任何事都是過猶不及阁将，
設(shè)計(jì)模式的六個(gè)設(shè)計(jì)原則也是一樣膏秫，制定這六個(gè)原則的目的并不是要我們刻板的遵守他們，而需要根據(jù)實(shí)際情況靈活運(yùn)用做盅。
對(duì)他們的遵守程度只要在一個(gè)合理的范圍內(nèi)缤削，就算是良好的設(shè)計(jì)。我們用一幅圖來說明一下吹榴。

圖中的每一條維度各代表一項(xiàng)原則亭敢，我們依據(jù)對(duì)這項(xiàng)原則的遵守程度在維度上畫一個(gè)點(diǎn)，
則如果對(duì)這項(xiàng)原則遵守的合理的話图筹，這個(gè)點(diǎn)應(yīng)該落在紅色的同心圓內(nèi)部帅刀；如果遵守的差，點(diǎn)將會(huì)在小圓內(nèi)部远剩；
如果過度遵守扣溺，點(diǎn)將會(huì)落在大圓外部。一個(gè)良好的設(shè)計(jì)體現(xiàn)在圖中瓜晤，應(yīng)該是六個(gè)頂點(diǎn)都在同心圓中的六邊形锥余。

在上圖中，設(shè)計(jì)1痢掠、設(shè)計(jì)2屬于良好的設(shè)計(jì)驱犹，他們對(duì)六項(xiàng)原則的遵守程度都在合理的范圍內(nèi)；
設(shè)計(jì)3足画、設(shè)計(jì)4設(shè)計(jì)雖然有些不足雄驹，但也基本可以接受；
設(shè)計(jì)5則嚴(yán)重不足锌云，對(duì)各項(xiàng)原則都沒有很好的遵守荠医；
而設(shè)計(jì)6則遵守過渡了吁脱，設(shè)計(jì)5和設(shè)計(jì)6都是迫切需要重構(gòu)的設(shè)計(jì)桑涎。

最終的目的：設(shè)計(jì)出高內(nèi)聚低耦合的架構(gòu)

軟件架構(gòu)設(shè)計(jì)的目的簡單說就是在保持軟件內(nèi)在聯(lián)系的前提下，
分解軟件系統(tǒng)兼贡，降低軟件系統(tǒng)開發(fā)的復(fù)雜性攻冷，而分解軟件系統(tǒng)的基本方法無外乎分層和分割。
但是在保持軟件內(nèi)在聯(lián)系的前提下遍希，如何分層分割系統(tǒng)等曼，分層分割到什么樣的程度，并不是一件容易的事，
這方面有各種各樣的分解方法禁谦，比如：關(guān)注點(diǎn)分離胁黑，面向方面，面向?qū)ο笾莶矗嫦蚪涌谏フ海嫦蚍?wù)，依賴注入遥皂，以及各種各樣的設(shè)計(jì)原則等力喷，

耦合性：也稱塊間聯(lián)系。指軟件系統(tǒng)結(jié)構(gòu)中各模塊間相互聯(lián)系緊密程度的一種度量演训。模塊之間聯(lián)系越緊密弟孟，其耦合性就越強(qiáng)，
       模塊的獨(dú)立性則越差样悟。模塊間耦合高低取決于模塊間接口的復(fù)雜性拂募、調(diào)用的方式及傳遞的信息

內(nèi)聚性：又稱塊內(nèi)聯(lián)系。指模塊的功能強(qiáng)度的度量乌奇，即一個(gè)模塊內(nèi)部各個(gè)元素彼此結(jié)合的緊密程度的度量没讲。
       若一個(gè)模塊內(nèi)各元素（語名之間、程序段之間）聯(lián)系的越緊密礁苗，則它的內(nèi)聚性就越高爬凑。

所謂高內(nèi)聚是指一個(gè)軟件模塊是由相關(guān)性很強(qiáng)的代碼組成，只負(fù)責(zé)一項(xiàng)任務(wù)试伙，也就是常說的單一責(zé)任原則嘁信。

對(duì)于低耦合，粗淺的理解是：一個(gè)完整的系統(tǒng)疏叨，模塊與模塊之間潘靖，盡可能的使其獨(dú)立存在。也就是說蚤蔓，
讓每個(gè)模塊卦溢，盡可能的獨(dú)立完成某個(gè)特定的子功能。模塊與模塊之間的接口秀又，盡量的少而簡單