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