六大設計原則

1、一、 單一職責原則：英文名稱是Single Responsibility Principle，簡稱SRP。有且只有一個原因引起類的變更。There should never be more than one reason for a class to change. 例如在電話類的設計中，接口包含三個方法：撥號，通話和掛電話。但是這個接口包含了兩個職責，撥號和掛電話屬于協(xié)議管理，通話屬于數(shù)據(jù)傳輸。不符合單一職責原則?？梢詫芴柡蛼祀娫捵鳛橐粋€接口，通話作為一個接口，一個類實現(xiàn)了這兩個接口，把兩個職責融合在一個類中，對外公布的是接口，而不是實現(xiàn)類。優(yōu)點：類的復雜度降低，提高了可讀性，可維護性，降

2、低了變更引起的風險。單一職責不僅適用于接口，類，還適用于方法，盡量使每個方法的職責清晰。二、里氏替換原則：Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it. 所有引用基類的地方必須透明地使用其子類的對象。 通俗的講，只要父類出現(xiàn)的地方，子類都可以出現(xiàn)，而且替換為子類也不會發(fā)生任何異常或錯誤，使用者根本不需要知道是子類還是父類。包含四層含義：1 子類必須完全實現(xiàn)父類的方法。2 子類可以有自己的方法。3

3、 覆蓋或實現(xiàn)父類的方法時，輸入?yún)?shù)可以放大。例如父類有一個的doSomething方法，其參數(shù)為（HashMap），而子類中重載了這個方法，參數(shù)為（Map），因為參數(shù)不一樣，所以不是覆寫，而是重載，此時，當子類當做父類使用時，傳入HashMap參數(shù)，執(zhí)行的為父類的方法。若反過來，傳入HashMap時，執(zhí)行的是子類的方法。4 覆蓋或實現(xiàn)父類的方法時，返回值要變小。 3和4條是為了保證版本升級時的兼容性，比如以前版本是創(chuàng)建了一個father類，新版本創(chuàng)建了子類，并使用子類，滿足上述兩條后可以實現(xiàn)系統(tǒng)兼容。傳遞不同的子類，三、依賴倒置原則（Dependence Inversion Principle

4、, DIP）：High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depends upon details. Details should depend upon abstractions.包含三層含義1 高層模塊不應該依賴底層模塊，兩者都應該依賴其抽象。2 抽象不應該依賴于細節(jié)3 細節(jié)應該依賴于抽象。簡單的說就是面向接口編程，模塊間的依賴是通過抽象發(fā)生的，實現(xiàn)類之間不發(fā)生直接的依賴關系，其依賴是通過接

5、口或者抽象類發(fā)生的。優(yōu)點：依賴倒置原則可以減少類間的耦合性，提高系統(tǒng)的穩(wěn)定性，降低并行開發(fā)引起的風險，提高代碼的可讀性和可維護性。實現(xiàn)類直接不直接發(fā)生依賴關系，降低了耦合性，采用接口編程，由于調用的是接口，不必等實現(xiàn)類完成，就可以對調用者進行開發(fā)，測試。例如在頂層模塊實現(xiàn)司機開車功能，司機和車都屬于底層。在編寫的過程中，要編寫司機和車的接口，司機里調用車時，調用的是接口，通過接口，構造函數(shù)或者SET方法給接口賦值。當車模型改變時，不需要修改底層的司機類。符合了單一職責，只有司機改變時，才能引起司機類的變化。依賴的三種實現(xiàn)方法：構造函數(shù)：上例中，建立司機類的時候，通過構造函數(shù)給司機類中的車接口賦

6、值。SET方法：在司機類中，增加一個PUBLIC 的SET方法，調用該方法時，給司機類中的車賦值。接口方法：在調用的車的方法參數(shù)中，有一個參數(shù)為車的接口。編程原則：1每個接口盡量有接口或者抽象類，或者抽象類接口都有。2變量的表面類型盡量是接口或者抽象類。第1條和第2條不是必須的，比如編寫工具類XXXUtils時。3盡量不要覆寫基類的方法。類間依賴的是抽象，覆寫了抽象的方法，會對依賴的穩(wěn)定性造成一定的影響?？偨Y：依賴倒置要求編程時，面向抽象或者接口。這就要求子類繼承時，盡量不要新增方法，否則按照依賴倒置原則編程，根本訪問不到子類新增的方法。四、接口隔離原則：Client should not b

7、e forced to depend upon interfaces that they dont use. (客戶端不應該依賴它不需要的接口。)The dependency of one class to another one should depend on the smallest possible interface. (類間的依賴關系應該建立在最小的接口上)根據(jù)第一種定義，客戶端需要什么接口就提供什么接口，把不需要的接口剔掉，這就需要對接口進行細化。在第二種定義中，要求接口細化。這兩種定義實質上都是要求建立單一接口。實例：比如星探查找美女，美女的定義是相貌美麗并且氣質好。如果在一個

8、接口里定義相貌美麗和氣質好會造成接口臃腫，如果美女的標準變了，會對接口造成影響。這里應該使美女實現(xiàn)相貌美麗和氣質好兩個接口，這樣星探的抽象類就依賴兩個接口，而不是一個臃腫的接口，靈活性增強。接口是我們設計時對外提供的契約，通過分散定義多個接口，可以預防未來變更的擴展，提高系統(tǒng)的靈活性和可維護性。接口設計原則1接口要盡量小。但是小是有限度的，不能違反單一職責原則，也就不能把一個職責拆分成兩個接口。2接口要高內聚。高內聚就是提高接口，類和模塊的處理能力，減少對外的交互。接口要盡量少的公布public方法，接口是對外的承諾，承諾的越少，對系統(tǒng)開發(fā)越有利，變更的風險就越少，同時有利于降低成本。3定制服

9、務。定制服務就是單獨為一個個體提供優(yōu)良的服務，我們在做系統(tǒng)設計時，也需要考慮系統(tǒng)之間或模塊之間的接口提供定制服務。這就要求接口只提供訪問者需要的方法。4接口設計是有限度的。接口設計粒度越小，系統(tǒng)越靈活，但是靈活的同時也會帶來結構的復雜化，開發(fā)難度增加，可維護性降低。最佳實踐一個接口只服務于一個子模塊或者業(yè)務邏輯通過業(yè)務邏輯壓縮接口中的public方法。被污染的接口盡量去修改，若修改的風險太大，則可以使用適配器模式進行轉化處理，五、迪米特原則（Law of Demeter, LoD）也成最小知識原則（Least Knowledge Principle ,LKP）：一個對象應該對其他對象有最少的了

10、解，通俗的講，一個類應該對自己需要耦合或調用的類知道得最少。四層含義：1只和朋友交流。迪米特原則還有一個英文解釋是：Only talk to your immediate friends（只與直接的朋友通信）。例如，教師向班長發(fā)送命令，數(shù)女生的個數(shù)。則教師中發(fā)送命令方法需要傳入班長類，由班長類執(zhí)行數(shù)女生個數(shù)。在這中情況下，在教師類中不應該建立女生類，而應該在班長類中建立女生類，對女生個數(shù)進行統(tǒng)計。 朋友類：出現(xiàn)在成員變量，或者輸入?yún)?shù)的類稱為方法類，而出現(xiàn)在方法體內部的類不屬于朋友類。因而在上例中，教師類中不應該出現(xiàn)女生類。 2朋友之間也是有距離的。例如在安裝軟件時，通過向導類，第一步安裝成功

11、可以安裝第二步，第二步安裝成功，可以執(zhí)行第三步。在這種情況下，向導類應該對外提供一個安裝方法，此方法根據(jù)判斷條件調用三步安裝方法，實現(xiàn)了整個安裝過程。而不是讓用戶去調用每一步安裝方法，并根據(jù)安裝是否成功，決定下一步安裝。 在與MES集成的項目中，提供服務的方法類很簡單，其主要實現(xiàn)都是調用其他類來實現(xiàn)的。3是自己的終究是自己的。在應用中可能出現(xiàn)這樣一個方法，放在本類中也可以，放在其他類中葉可以。衡量準則如下：如果一個方法放在本類中，即不增加類間關系，也不會對本類產生負面影響，就放置在本類中。當然，如果該方法有多個類調用，則可放入工具類中。4慎用Serializable，如果在項目中，采用遠程調用

12、方法傳遞值對象，該對象就必須實現(xiàn)Serializable接口，也就是對網(wǎng)絡傳輸?shù)膶ο筮M行序列號，否則會出現(xiàn)異常。最佳實踐：迪米特法則的核心就是類間解耦，弱耦合，只有解耦后，復用率才可以提高。但是這樣會導致產生大量的中轉類或者跳轉類，導致系統(tǒng)的復雜性提高，同時也給維護帶來難度。在實際項目中，一個類跳轉兩次才能訪問到另個一個類，就需要進行重構了。六、開閉原則 ：Software entities like classes, modules and functions should be open for extension but close for modifications. （一個軟件實體如

13、類，模塊和函數(shù)應該對擴展開放，對修改關閉） 開閉原則要求盡量通過擴展軟件實體的方法來適應變化，而不是通過修改已有的代碼來完成變化。它是為軟件實體的未來而制定的對現(xiàn)行開發(fā)設計進行約束的一個原則。簡單例子：以圖書銷售為例，圖書有三個屬性，價格，書名以及作者。小說書繼承了圖書接口。如果有一天圖小說書打折，修改方案有三種：（1）修改圖書接口，在接口中增加獲得打折價格方法。缺點是所有實現(xiàn)圖書的接口都需要增加這種方法。（2）直接修改小說類中獲得價格的方法。缺點是：無論誰都看不到小說書的原價。（3）新寫一個打折小說類，繼承小說類，覆寫其中的價格方法。銷售時，將打折小說類賦給圖書接口。采購人員查看價格時，可以通過常見小說類實現(xiàn)。變化分類：我們把變化分為三種。（1）邏輯變化 只變化一個邏輯，不涉及其它模塊。可以通過修改類中的方法來完成。前提條件是所有依賴或者關聯(lián)的類都按照相同的邏輯處理。（2）子模塊變化 一個子模塊變化，會引起高層的變化。因此通過擴展完成變化時，高層次的模塊修改也是必然的。（3）可見視圖的變化 如何應用開閉原則：（1）抽象約束 通過接口或者抽象類可以約束一組可能變化的行為，并且能夠實現(xiàn)對擴展開放。包含三層和含義：第一，通過接口和抽象類約束擴展，多擴展進行邊界限定，不允許出現(xiàn)在接口