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