C#設(shè)計(jì)的六大原則是面向?qū)ο笳Z(yǔ)言開(kāi)發(fā)過(guò)程中推薦的一些指導(dǎo)性的原則，是遇到各種場(chǎng)景和問(wèn)題的解決方案和思路沉淀，俗稱，套路，下面我們簡(jiǎn)單聊聊這6大設(shè)計(jì)原則。
設(shè)計(jì)模式六大原則（1）：?jiǎn)我宦氊?zé)原則定義：不要存在多于一個(gè)導(dǎo)致類變更的原因。通俗的說(shuō)，即一個(gè)類只負(fù)責(zé)一項(xiàng)職責(zé)。問(wèn)題由來(lái)：類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é)原的優(yōu)點(diǎn)有：
1.可以降低類的復(fù)雜度，一個(gè)類只負(fù)責(zé)一項(xiàng)職責(zé)，其邏輯肯定要比負(fù)責(zé)多項(xiàng)職責(zé)簡(jiǎn)單的多；
2.提高類的可讀性，提高系統(tǒng)的可維護(hù)性;
3.變更引起的風(fēng)險(xiǎn)降低，變更是必然的，如果單一職責(zé)原則遵守的好，當(dāng)修改一個(gè)功能時(shí)，可以顯著降低對(duì)其他功能的影響。
需要說(shuō)明的一點(diǎn)是單一職責(zé)原則不只是面向?qū)ο缶幊趟枷胨赜械模灰悄K化的程序設(shè)計(jì)，都適用單一職責(zé)原則
遵循單一職責(zé)原則的代碼設(shè)計(jì):class Animal{ public void breathe(String animal) { System.out.println(animal+"呼吸空氣"); }
public void breathe2(String animal) { System.out.println(animal+"呼吸水"); }}
public class Client{ public static void main(String[] args) { Animal animal = new Animal(); animal.breathe("牛"); animal.breathe("羊"); animal.breathe("豬"); animal.breathe2("魚(yú)"); }}
設(shè)計(jì)模式六大原則（2）：里氏替換原則肯定有不少人跟我剛看到這項(xiàng)原則的時(shí)候一樣，對(duì)這個(gè)原則的名字充滿疑惑。其實(shí)原因就是這項(xiàng)原則最早是在1988年，由麻省理工學(xué)院的一位姓里的女士（BarbaraLiskov）提出來(lái)的。定義1：如果對(duì)每一個(gè)類型為 T1的對(duì)象 o1，都有類型為 T2 的對(duì)象o2，使得以 T1定義的所有程序 P 在所有的對(duì)象 o1 都代換成 o2 時(shí)，程序 P 的行為沒(méi)有發(fā)生變化，那么類型 T2 是類型 T1 的子類型。定義2：所有引用基類的地方必須能透明地使用其子類的對(duì)象。問(wèn)題由來(lái)：有一功能P1，由類A完成。現(xiàn)需要將功能P1進(jìn)行擴(kuò)展，擴(kuò)展后的功能為P，其中P由原有功能P1與新功能P2組成。新功能P由類A的子類B來(lái)完成，則子類B在完成新功能P2的同時(shí)，有可能會(huì)導(dǎo)致原有功能P1發(fā)生故障。解決方案：當(dāng)使用繼承時(shí)，遵循里氏替換原則。類B繼承類A時(shí)，除添加新的方法完成新增功能P2外，盡量不要重寫(xiě)父類A的方法，也盡量不要重載父類A的方法。class A{ public int func1(int a, int b) { return a-b; }}class B extends A{ public int func1(int a, int b) { return a+b; } public int func2(int a, int b) { return func1(a,b)+100; }}
public class Client{ public static void main(String[] args) { B b = new B(); System.out.println("100-50="+b.func1(100, 50)); System.out.println("100-80="+b.func1(100, 80)); System.out.println("100+20+100="+b.func2(100, 20)); }}
里氏替換原則通俗的來(lái)講就是：子類可以擴(kuò)展父類的功能，但不能改變父類原有的功能。它包含以下4層含義：
1.子類可以實(shí)現(xiàn)父類的抽象方法，但不能覆蓋父類的非抽象方法。
2. 子類中可以增加自己特有的方法。
3. 當(dāng)子類的方法重載父類的方法時(shí)，方法的前置條件（即方法的形參）要比父類方法的輸入?yún)?shù)更寬松。
4.當(dāng)子類的方法實(shí)現(xiàn)父類的抽象方法時(shí)，方法的后置條件（即方法的返回值）要比父類更嚴(yán)格。
看上去很不可思議，因?yàn)槲覀儠?huì)發(fā)現(xiàn)在自己編程中常常會(huì)違反里氏替換原則，程序照樣跑的好好的。所以大家都會(huì)產(chǎn)生這樣的疑問(wèn)，假如我非要不遵循里氏替換原則會(huì)有什么后果？
后果就是：你寫(xiě)的代碼出問(wèn)題的幾率將會(huì)大大增加。
設(shè)計(jì)模式六大原則（3）：依賴倒置原則
定義：高層模塊不應(yīng)該依賴低層模塊，二者都應(yīng)該依賴其抽象；抽象不應(yīng)該依賴細(xì)節(jié)；細(xì)節(jié)應(yīng)該依賴抽象。問(wèn)題由來(lái)：類A直接依賴類B，假如要將類A改為依賴類C，則必須通過(guò)修改類A的代碼來(lái)達(dá)成。這種場(chǎng)景下，類A一般是高層模塊，負(fù)責(zé)復(fù)雜的業(yè)務(wù)邏輯；類B和類C是低層模塊，負(fù)責(zé)基本的原子操作；假如修改類A，會(huì)給程序帶來(lái)不必要的風(fēng)險(xiǎn)。解決方案：將類A修改為依賴接口I，類B和類C各自實(shí)現(xiàn)接口I，類A通過(guò)接口I間接與類B或者類C發(fā)生聯(lián)系，則會(huì)大大降低修改類A的幾率。依賴倒置原則基于這樣一個(gè)事實(shí)：相對(duì)于細(xì)節(jié)的多變性，抽象的東西要穩(wěn)定的多，以抽象為基礎(chǔ)搭建起來(lái)的架構(gòu)比以細(xì)節(jié)為基礎(chǔ)搭建起來(lái)的架構(gòu)要穩(wěn)定的多。interface IReader{ public String getContent();} class Newspaper implements IReader { public String getContent() { return "林書(shū)豪17+9助尼克斯擊敗老鷹……"; }}class Book implements IReader{ public String getContent() { return "很久很久以前有一個(gè)阿拉伯的故事……"; }}
class Mother{ public void narrate(IReader reader) { System.out.println("媽媽開(kāi)始講故事"); 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ì)模式六大原則（4）：接口隔離原則定義：客戶端不應(yīng)該依賴它不需要的接口；一個(gè)類對(duì)另一個(gè)類的依賴應(yīng)該建立在最小的接口上。
問(wèn)題由來(lái)：類A通過(guò)接口I依賴類B，類C通過(guò)接口I依賴類D，如果接口I對(duì)于類A和類B來(lái)說(shuō)不是最小接口，則類B和類D必須去實(shí)現(xiàn)他們不需要的方法。
解決方案：將臃腫的接口I拆分為獨(dú)立的幾個(gè)接口，類A和類C分別與他們需要的接口建立依賴關(guān)系。也就是采用接口隔離原則。interface I1 { public void method1();}
interface I2 { public void method2(); public void method3();}
interface I3 { public void method4(); public void method5();}
class A{ public void depend1(I1 i) { i.method1(); } public void depend2(I2 i) { i.method2(); } public void depend3(I2 i) { i.method3(); }}
class B implements I1, I2{ public void method1() { System.out.println("類B實(shí)現(xiàn)接口I1的方法1"); } public void method2() { System.out.println("類B實(shí)現(xiàn)接口I2的方法2"); } public void method3() { System.out.println("類B實(shí)現(xiàn)接口I2的方法3"); }}class C{ public void depend1(I1 i) { i.method1(); } public void depend2(I3 i) { i.method4(); } public void depend3(I3 i) { i.method5(); }}class D implements I1, I3{ public void method1() { System.out.println("類D實(shí)現(xiàn)接口I1的方法1"); } public void method4() { System.out.println("類D實(shí)現(xiàn)接口I3的方法4"); } public void method5() { System.out.println("類D實(shí)現(xiàn)接口I3的方法5"); }}
接口隔離原則的含義是：建立單一接口，不要建立龐大臃腫的接口，盡量細(xì)化接口，接口中的方法盡量少。也就是說(shuō)，我們要為各個(gè)類建立專用的接口，而不要試圖去建立一個(gè)很龐大的接口供所有依賴它的類去調(diào)用。本文例子中，將一個(gè)龐大的接口變更為3個(gè)專用的接口所采用的就是接口隔離原則。在程序設(shè)計(jì)中，依賴幾個(gè)專用的接口要比依賴一個(gè)綜合的接口更靈活。接口是設(shè)計(jì)時(shí)對(duì)外部設(shè)定的“契約”，通過(guò)分散定義多個(gè)接口，可以預(yù)防外來(lái)變更的擴(kuò)散，提高系統(tǒng)的靈活性和可維護(hù)性。
說(shuō)到這里，很多人會(huì)覺(jué)的接口隔離原則跟之前的單一職責(zé)原則很相似，其實(shí)不然。其一，單一職責(zé)原則原注重的是職責(zé)；而接口隔離原則注重對(duì)接口依賴的隔離。其二，單一職責(zé)原則主要是約束類，其次才是接口和方法，它針對(duì)的是程序中的實(shí)現(xiàn)和細(xì)節(jié)；而接口隔離原則主要約束接口接口，主要針對(duì)抽象，針對(duì)程序整體框架的構(gòu)建。
采用接口隔離原則對(duì)接口進(jìn)行約束時(shí)，要注意以下幾點(diǎn)：
1.接口盡量小，但是要有限度。對(duì)接口進(jìn)行細(xì)化可以提高程序設(shè)計(jì)靈活性是不掙的事實(shí)，但是如果過(guò)小，則會(huì)造成接口數(shù)量過(guò)多，使設(shè)計(jì)復(fù)雜化。所以一定要適度。
2.為依賴接口的類定制服務(wù)，只暴露給調(diào)用的類它需要的方法，它不需要的方法則隱藏起來(lái)。只有專注地為一個(gè)模塊提供定制服務(wù)，才能建立最小的依賴關(guān)系。
3.提高內(nèi)聚，減少對(duì)外交互。使接口用最少的方法去完成最多的事情。
運(yùn)用接口隔離原則，一定要適度，接口設(shè)計(jì)的過(guò)大或過(guò)小都不好。設(shè)計(jì)接口的時(shí)候，只有多花些時(shí)間去思考和籌劃，才能準(zhǔn)確地實(shí)踐這一原則。
設(shè)計(jì)模式六大原則（5）：迪米特法則定義：一個(gè)對(duì)象應(yīng)該對(duì)其他對(duì)象保持最少的了解。
問(wèn)題由來(lái)：類與類之間的關(guān)系越密切，耦合度越大，當(dāng)一個(gè)類發(fā)生改變時(shí)，對(duì)另一個(gè)類的影響也越大。自從我們接觸編程開(kāi)始，就知道了軟件編程的總的原則：低耦合，高內(nèi)聚。無(wú)論是面向過(guò)程編程還是面向?qū)ο缶幊?，只有使各個(gè)模塊之間的耦合盡量的低，才能提高代碼的復(fù)用率。低耦合的優(yōu)點(diǎn)不言而喻，但是怎么樣編程才能做到低耦合呢？那正是迪米特法則要去完成的。迪米特法則又叫最少知道原則，最早是在1987年由美國(guó)NortheasternUniversity的Ian Holland提出。通俗的來(lái)講，就是一個(gè)類對(duì)自己依賴的類知道的越少越好。也就是說(shuō)，對(duì)于被依賴的類來(lái)說(shuō)，無(wú)論邏輯多么復(fù)雜，都盡量地的將邏輯封裝在類的內(nèi)部，對(duì)外除了提供的public方法，不對(duì)外泄漏任何信息。迪米特法則還有一個(gè)更簡(jiǎn)單的定義：只與直接的朋友通信。首先來(lái)解釋一下什么是直接的朋友：每個(gè)對(duì)象都會(huì)與其他對(duì)象有耦合關(guān)系，只要兩個(gè)對(duì)象之間有耦合關(guān)系，我們就說(shuō)這兩個(gè)對(duì)象之間是朋友關(guān)系。耦合的方式很多，依賴、關(guān)聯(lián)、組合、聚合等。其中，我們稱出現(xiàn)成員變量、方法參數(shù)、方法返回值中的類為直接的朋友，而出現(xiàn)在局部變量中的類則不是直接的朋友。也就是說(shuō)，陌生的類最好不要作為局部變量的形式出現(xiàn)在類的內(nèi)部。class SubCompanyManager{ public List<SubEmployee> getAllEmployee() { List<SubEmployee> list = new ArrayList<SubEmployee>(); for(int i=0; i<100; i++) { SubEmployee emp = new SubEmployee(); emp.setId("分公司"+i); list.add(emp); } return list; } public void printEmployee(){ List<SubEmployee> list = this.getAllEmployee(); for(SubEmployee e:list) { System.out.println(e.getId()); } }}
class CompanyManager{ public List<Employee> getAllEmployee() { List<Employee> list = new ArrayList<Employee>(); for(int i=0; i<30; i++) { Employee emp = new Employee(); emp.setId("總公司"+i); list.add(emp); } return list; } public void printAllEmployee(SubCompanyManager sub){ sub.printEmployee(); List<Employee> list2 = this.getAllEmployee(); for(Employee e:list2) { System.out.println(e.getId()); } }}
設(shè)計(jì)模式六大原則（6）：開(kāi)閉原則定義：一個(gè)軟件實(shí)體如類、模塊和函數(shù)應(yīng)該對(duì)擴(kuò)展開(kāi)放，對(duì)修改關(guān)閉。
問(wèn)題由來(lái)：在軟件的生命周期內(nèi)，因?yàn)樽兓?、升?jí)和維護(hù)等原因需要對(duì)軟件原有代碼進(jìn)行修改時(shí)，可能會(huì)給舊代碼中引入錯(cuò)誤，也可能會(huì)使我們不得不對(duì)整個(gè)功能進(jìn)行重構(gòu)，并且需要原有代碼經(jīng)過(guò)重新測(cè)試。解決方案：當(dāng)軟件需要變化時(shí)，盡量通過(guò)擴(kuò)展軟件實(shí)體的行為來(lái)實(shí)現(xiàn)變化，而不是通過(guò)修改已有的代碼來(lái)實(shí)現(xiàn)變化。開(kāi)閉原則是面向?qū)ο笤O(shè)計(jì)中最基礎(chǔ)的設(shè)計(jì)原則，它指導(dǎo)我們?nèi)绾谓⒎€(wěn)定靈活的系統(tǒng)。開(kāi)閉原則可能是設(shè)計(jì)模式六項(xiàng)原則中定義最模糊的一個(gè)了，它只告訴我們對(duì)擴(kuò)展開(kāi)放，對(duì)修改關(guān)閉，可是到底如何才能做到對(duì)擴(kuò)展開(kāi)放，對(duì)修改關(guān)閉，并沒(méi)有明確的告訴我們。以前，如果有人告訴我“你進(jìn)行設(shè)計(jì)的時(shí)候一定要遵守開(kāi)閉原則”，我會(huì)覺(jué)的他什么都沒(méi)說(shuō)，但貌似又什么都說(shuō)了。因?yàn)殚_(kāi)閉原則真的太虛了。到這里，設(shè)計(jì)模式的六大原則就寫(xiě)完了。主要參考書(shū)籍有《設(shè)計(jì)模式》《設(shè)計(jì)模式之禪》《大話設(shè)計(jì)模式》以及網(wǎng)上一些零散的文章，但主要內(nèi)容主要還是我本人對(duì)這六個(gè)原則的感悟。寫(xiě)出來(lái)的目的一方面是對(duì)這六項(xiàng)原則系統(tǒng)地整理一下，一方面也與廣大的網(wǎng)友分享，因?yàn)樵O(shè)計(jì)模式對(duì)編程人員來(lái)說(shuō)，的確非常重要。正如有句話叫做一千個(gè)讀者眼中有一千個(gè)哈姆雷特，如果大家對(duì)這六項(xiàng)原則的理解跟我有所不同，歡迎留言，大家共同探討。
該文章在 2023/2/27 10:55:15 編輯過(guò)
400 186 1886
