设计原则——设计模式基础
在講設(shè)計(jì)原則之前，我先強(qiáng)制灌輸大家一波雞湯，提倡
面向接口編程，代碼的設(shè)計(jì)更重要的是考慮以后的擴(kuò)展和可維護(hù)性
大家?guī)е@樣的思維來學(xué)習(xí)設(shè)計(jì)模式以及設(shè)計(jì)原則，慢慢就意會(huì)這波毒雞湯了。
先聲明一點(diǎn)就是老衲的blog，也是邊學(xué)習(xí)，邊記錄，而后以討論交流的方式敘述，有什么不對(duì)的地方大家多多擔(dān)待。
設(shè)計(jì)原則
單一職責(zé)原則（Single Responsibility Principle， 簡稱是SRP）
老衲是一位粗鄙之人，所以描述也是盡可能的白話哈~
定義
白話單一職責(zé)：首先，顧名思義，什么是單一職責(zé)？就是某玩意，專門負(fù)責(zé)某個(gè)東西，就譬如說，你的手機(jī)屏幕，他就只負(fù)責(zé)顯示，不管顯示app還是視頻還是小黃書，只要是顯示的活，他就干，而且他就只干顯示的活，這就是單一職責(zé)，那么放到術(shù)語里面就是咱們?cè)O(shè)計(jì)的接口或者類，盡量遵循此原則，有什么好處賴？
- 類的復(fù)雜性降低， 實(shí)現(xiàn)什么職責(zé)都有清晰明確的定義
- 可讀性提高， 復(fù)雜性降低， 那當(dāng)然可讀性提高了
- 可維護(hù)性提高， 可讀性提高， 那當(dāng)然更容易維護(hù)了
- 變更引起的風(fēng)險(xiǎn)降低， 變更是必不可少的， 如果接口的單一職責(zé)做得好， 一個(gè)接口修
改只對(duì)相應(yīng)的實(shí)現(xiàn)類有影響， 對(duì)其他的接口無影響， 這對(duì)系統(tǒng)的擴(kuò)展性、 維護(hù)性都有非常大
的幫助
這一波好處摘自設(shè)計(jì)模式之禪，總結(jié)下來就是，看見這個(gè)接口所聲明的方法，你就知道功能都有什么，初學(xué)者或者初接手的人都可以很快融入到代碼中進(jìn)行迭代和維護(hù)了。
然而道理是這個(gè)道理，但是具體在設(shè)計(jì)代碼的時(shí)候，還是要考慮到具體的應(yīng)用下。用書中的話描述就是
單一職責(zé)原則提出了一個(gè)編寫程序的標(biāo)準(zhǔn)， 用“職責(zé)”或“變化原因”來衡量接口或
類設(shè)計(jì)得是否優(yōu)良， 但是“職責(zé)”和“變化原因”都是不可度量的， 因項(xiàng)目而異， 因環(huán)境而異
code
OK，結(jié)合上面說的小Demo，接下來來一杯Java解解渴
interface IScreenDisplay {/*** display image on screen** @param image*/void displayImage(String image);/*** display a text on screen** @param text*/void displayText(String text);/*** display a video on screen** @param video*/void displayVideo(String video); }上來就是我們的小接口，屏幕顯示，干什么玩意呢？自行翻譯不謝~
然后是我們的實(shí)現(xiàn)類
static class Phone implements IScreenDisplay {@Overridepublic void displayImage(String image) {System.out.println("displayImage:" + image);}@Overridepublic void displayText(String text) {System.out.println("displayText:" + text);}@Overridepublic void displayVideo(String video) {System.out.println("displayVideo:" + video);} }實(shí)現(xiàn)類就是干具體的活了，國際慣例sout輸出~
public static void main(String[] args) {IScreenDisplay phone = new Phone();phone.displayImage("ic_launcher.png");phone.displayText("Hello Done!");phone.displayVideo("xiao huang pian.avi"); }這一套降龍十八掌走下來結(jié)果:
displayImage:ic_launcher.png displayText:Hello Done! displayVideo:xiao huang pian.avi多囂張？多簡單？當(dāng)后期review一看，咱們的接口告訴你只負(fù)責(zé)顯示，可以顯示文字，圖片和視頻，至于什么時(shí)候顯示，顯示什么內(nèi)容，那我不管，我就顯示，唯一讓我引起變化的是什么？當(dāng)然是內(nèi)容咯~
總結(jié)一番便是
接口一定要做到單一職責(zé)， 類的設(shè)計(jì)盡量做到只有一個(gè)
原因引起變化
里氏替換原則（LiskovSubstitution Principle， LSP）
此原則相較于上面的單一職責(zé)，要復(fù)雜一些，這里引用書中的原話（一定要認(rèn)真閱讀），后面會(huì)通過白話做出相關(guān)解釋哈~
首先要理解的是繼承的特點(diǎn)
- 代碼共享， 減少創(chuàng)建類的工作量， 每個(gè)子類都擁有父類的方法和屬性
- 提高代碼的重用性
- 子類可以形似父類，但又異于父類， “龍生龍， 鳳生鳳，老鼠生來會(huì)打洞”是說子擁有父的“種”，“世界上沒有兩片完全相同的葉子”是指明子與父的不同
- 提高代碼的可擴(kuò)展性，實(shí)現(xiàn)父類的方法就可以“為所欲為”了，君不見很多開源框架的擴(kuò)展接口都是通過繼承父類來完成的
- 提高產(chǎn)品或項(xiàng)目的開放性
上面是優(yōu)點(diǎn)，下面是缺點(diǎn)
- 繼承是侵入性的。 只要繼承， 就必須擁有父類的所有屬性和方法
- 降低代碼的靈活性。子類必須擁有父類的屬性和方法，讓子類自由的世界中多了些約束
- 增強(qiáng)了耦合性。當(dāng)父類的常量、變量和方法被修改時(shí)，需要考慮子類的修改，而且在缺乏規(guī)范的環(huán)境下，這種修改可能帶來非常糟糕的結(jié)果——大段的代碼需要重構(gòu)
定義
- 看不懂，繞口定義：
If for each object o1 of type S there is an object o2 oftype T such that for all programs P defined in terms of T,the behavior of P is unchanged when o1 issubstituted for o2 then S is a subtype of T.（如果對(duì)每一個(gè)類型為S的對(duì)象o1， 都有類型為T的對(duì)象o2， 使得以T定義的所有程序P在所有的對(duì)象o1都代換成o2時(shí)， 程序P的行為沒有發(fā)生變
化， 那么類型S是類型T的子類型。 ）
- 通俗易懂，親民定義：
Functions that use pointers or references to base classes must be able to useobjects of derived classes without knowing it.（所有引用基類的地方必須能透明地使用其子類的對(duì)象。 ）
只要父類能出現(xiàn)的地方子類就可以出現(xiàn)， 而且
替換為子類也不會(huì)產(chǎn)生任何錯(cuò)誤或異常， 使用者可能根本就不需要知道是父類還是子類。 但
是， 反過來就不行了， 有子類出現(xiàn)的地方， 父類未必就能適應(yīng)。
- 子類必須完全實(shí)現(xiàn)父類的方法
如果子類不能完整地實(shí)現(xiàn)父類的方法，或者父類的某些方法在子類中已經(jīng)發(fā)生“畸變”，則建議斷開父子繼承關(guān)系， 采用依賴、聚集、 組合等關(guān)系代替繼承。
- 子類可以有自己的個(gè)性
向下轉(zhuǎn)型（downcast）是不安全的， 從里氏替換原則來看，就是有子類出現(xiàn)的地方父類未必就可以出現(xiàn)
- 覆蓋或?qū)崿F(xiàn)父類的方法時(shí)輸入?yún)?shù)可以被放大
里氏替換原則也要求制定一個(gè)契約， 就是父類或接口，這種設(shè)計(jì)方法也叫做Design by Contract（契約設(shè)計(jì)） ，與里氏替換原則有著異曲同工之妙。 契約制定了， 也就同時(shí)制定了前置條件和后置條件， 前置條件就是你要讓我執(zhí)行，就必須滿足我的條件； 后置條件就是我執(zhí)行完了需要反饋， 標(biāo)準(zhǔn)是什么。
- 覆寫或?qū)崿F(xiàn)父類的方法時(shí)輸出結(jié)果可以被縮小
采用里氏替換原則的目的就是增強(qiáng)程序的健壯性，版本升級(jí)時(shí)也可以保持非常好的兼容性。即使增加子類，原有的子類還可以繼續(xù)運(yùn)行,每個(gè)子類對(duì)應(yīng)不同的業(yè)務(wù)含義，使用父類作為參數(shù)，傳遞不同的子類完成不同的業(yè)務(wù)邏輯
白話方式總結(jié)一下上面的內(nèi)容:
里氏替換原則更像是一種java繼承的規(guī)范用法，"extends"嘛，大家都用過的東西，可以這么用那么用隨便用，想用就用，但是寫完以后發(fā)現(xiàn)沒有卵用，用是用了，但是有什么奧妙還是不太清楚，為什么要用它？
咱們經(jīng)常談到的一個(gè)詞：抽取，譬如說activity，這個(gè)活動(dòng)要setContentView，那個(gè)活動(dòng)也要setContentView，這個(gè)活動(dòng)要上下文，那個(gè)活動(dòng)也要上下文，誒~這時(shí)候我們就開始搞一個(gè)BaseActivity的東西，然后讓所有子類去重寫獲取布局ID，同時(shí)父類直接拿到自己的上下文對(duì)象，子類直接使用即可。
那么是不是我們的活動(dòng)程序代碼邏輯無論ams(自行百度)怎么使，你創(chuàng)建的這個(gè)活動(dòng)都好使，符合咱們android體系的健壯性，另外你想實(shí)現(xiàn)的黑科技是不是都可以在自己的活動(dòng)里面去實(shí)現(xiàn)，當(dāng)然這里的設(shè)計(jì)并不是完全符合里氏替換原則，姑且斷章取義，您就這么斷章取義的理解即可，另外如果老衲說的有什么不對(duì)的地方，歡迎大家指正批評(píng)~
還記得上面提到過的Java中繼承帶來的優(yōu)缺點(diǎn)嗎？咱們的里氏替換原則就是一個(gè)“揚(yáng)長避短”的做法，具體怎么搞？code一下見分曉
code
還是手機(jī)的例子，這次咱們不說屏幕，說品牌，先來個(gè)抽象手機(jī)
abstract class AbsPhone {/*** 使用*/public abstract void use(); }臥槽，就那么簡單，抽象一個(gè)使用的方法~
OK，接下來是子類們
很簡單，就是諾基亞，錘子和蘋果三個(gè)街機(jī)，這里并沒有任何對(duì)這些品牌的觀點(diǎn)，這是假借名義，傳輸知識(shí)用
再然后必須有一個(gè)使用者嘛
然后我們來用這些兄dei跑一把
public static void main(String[] args) {Person coke = new Person("庫克");coke.setPhone(new ApplePhone());Person laoluo = new Person("老羅");laoluo.setPhone(new TPhone());Person bill = new Person("比爾蓋茨");bill.setPhone(new NokiaPhone());coke.communicate();laoluo.communicate();bill.communicate(); }sout
庫克掏出手機(jī)了... 先讓蘋果特有鈴聲響一陣...嗚嗚嗚 蘋果 zhuang bi 專業(yè)戶 老羅掏出手機(jī)了... 錘子 情懷戶 比爾蓋茨掏出手機(jī)了... 砸核桃 實(shí)用戶爽哉，爽在哪里了？咱們的person對(duì)象只知道自己有個(gè)手機(jī)，這個(gè)手機(jī)能執(zhí)行communicate操作，什么手機(jī)我不管，我只管用它。術(shù)語就是，邏輯代碼不管實(shí)現(xiàn)，只需要持有著抽象類，然后執(zhí)行抽象類提供的方法即可，就算以后擴(kuò)展了其他的子類，也不影響我之前的業(yè)務(wù)邏輯，子類完全繼承了父類，同時(shí)在不改變方法本身的邏輯下增添了自己的特色，同時(shí)也符合父類出現(xiàn)的地方，就可以替換成子類
請(qǐng)大家仔細(xì)咀嚼下面這兩段話:
采用里氏替換原則的目的就是增強(qiáng)程序的健壯性， 版本升級(jí)時(shí)也可以保持非常好的兼容性。 即使增加子類， 原有的子類還可以繼續(xù)運(yùn)行。 在實(shí)際項(xiàng)目中， 每個(gè)子類對(duì)應(yīng)不同的業(yè)務(wù)含義， 使用父類作為參數(shù)， 傳遞不同的子類完成不同的業(yè)務(wù)邏輯
對(duì)于基類中定義的所有子程序，用在它的任何一個(gè)派生類中時(shí)的含義都應(yīng)該是相同的。這樣繼承才不會(huì)增加復(fù)雜度，基類才能真正被復(fù)用，而派生類也能夠在基類的基礎(chǔ)上增加新的行為。如果我們必須要不斷地思考不同派生類的實(shí)現(xiàn)在語義上的差異，繼承就只會(huì)增加復(fù)雜度了。
本著負(fù)責(zé)人的態(tài)度，老衲還是把樹立的這段話copy過來，望大家酌情使用參考:
在項(xiàng)目中，采用里氏替換原則時(shí)，盡量避免子類的“個(gè)性”，一旦子類有“個(gè)性”，這個(gè)子類和父類之間的關(guān)系就很難調(diào)和了，把子類當(dāng)做父類使用，子類的“個(gè)性”被抹殺——委屈了點(diǎn)；把子類單獨(dú)作為一個(gè)業(yè)務(wù)來使用，則會(huì)讓代碼間的耦合關(guān)系變得撲朔迷離——缺乏類替換的標(biāo)準(zhǔn)
依賴倒置原則（Dependence Inversion Principle,DIP）
依賴倒置是什么鬼？純說感覺也說不明白，白話點(diǎn)來說就是各種注入，依賴的接口注入，就是咱們的接口不依賴實(shí)現(xiàn)，而具體的實(shí)現(xiàn)類去組裝這些接口，簡單粗暴的解釋就是，
面向接口編程（OOD）
祭出官方釋義就是:
High level modules should not depend upon low level modules.Both should depend upon
abstractions.Abstractions should not depend upon details.Details should depend upon abstractions
- 高層模塊不應(yīng)該依賴低層模塊， 兩者都應(yīng)該依賴其抽象
- 抽象不應(yīng)該依賴細(xì)節(jié)
- 細(xì)節(jié)應(yīng)該依賴抽象
定義
你好，我是勤勞的搬運(yùn)工
抽象就是指接口或抽象類，兩者都是不能直接被實(shí)例化的；細(xì)節(jié)就是實(shí)現(xiàn)類，實(shí)現(xiàn)接口或繼承抽象類而產(chǎn)生的類就是細(xì)節(jié)，其特點(diǎn)就是可以直接被實(shí)例化，也就是可以加上一個(gè)關(guān)鍵字new產(chǎn)生一個(gè)對(duì)象
- 模塊間的依賴通過抽象發(fā)生， 實(shí)現(xiàn)類之間不發(fā)生直接的依賴關(guān)系， 其依賴關(guān)系是通過接口或抽象類產(chǎn)生的
- 接口或抽象類不依賴于實(shí)現(xiàn)類
- 實(shí)現(xiàn)類依賴接口或抽象類
那么采用依賴倒置的優(yōu)勢(shì)在哪里？就是
減少類間的耦合性， 提高系統(tǒng)的穩(wěn)定性，降低并行開發(fā)引起的風(fēng)險(xiǎn)，提高代碼的可讀性和可維護(hù)性，穩(wěn)定性較高的設(shè)計(jì)，在周圍環(huán)境頻繁變化的時(shí)候，依然可以做到“我自巋然不動(dòng)”
那么要如何遵循依賴倒置原則去設(shè)計(jì)代碼呢？首先，我們的始終遵循
抽象不依賴細(xì)節(jié)
在新增加低層模塊時(shí)，只修改了業(yè)務(wù)場景類，也就是高層模塊，對(duì)其他低層模塊如Driver類不需要做任何修改，業(yè)務(wù)就可以運(yùn)行，把“變更”引起的風(fēng)險(xiǎn)擴(kuò)散降到最低
如果兩個(gè)類直接存在依賴關(guān)系，那么連接他們之間的橋梁就是接口，不依賴具體的低層模塊
抽象是對(duì)實(shí)現(xiàn)的約束，對(duì)依賴者而言，也是一種契約，不僅僅約束自己，還同時(shí)約束自己與外部的關(guān)系，其目的是保證所有的細(xì)節(jié)不脫離契約的范疇，確保約束雙方按照既定的契約（抽象）共同發(fā)展，只要抽象這根基線在，細(xì)節(jié)就脫離不了這個(gè)圈圈，始終讓你的對(duì)象做到“言必信， 行必果”
常用依賴傳遞，只要做到抽象依賴，即使是多層的依賴傳遞也無所畏懼
code
依賴倒置原則的本質(zhì)就是通過抽象（接口或抽象類） 使各個(gè)類或模塊的實(shí)現(xiàn)彼此獨(dú)立，
不互相影響， 實(shí)現(xiàn)模塊間的松耦合
- 每個(gè)類盡量都有接口或抽象類， 或者抽象類和接口兩者都具備
這是依賴倒置的基本要求， 接口和抽象類都是屬于抽象的， 有了抽象才可能依賴倒置。 - 變量的表面類型盡量是接口或者是抽象類
- 任何類都不應(yīng)該從具體類派生
- 盡量不要覆寫基類的方法(類間依賴的是抽象， 覆寫了抽象方法， 對(duì)依賴的穩(wěn)定性會(huì)產(chǎn)生一定的影響)
- 結(jié)合里氏替換原則使用(接口負(fù)責(zé)定義public屬性和方法， 并且聲明與其他對(duì)象的依賴關(guān)系，抽象類負(fù)責(zé)公共構(gòu)造部分的實(shí)現(xiàn)，實(shí)現(xiàn)類準(zhǔn)確的實(shí)現(xiàn)業(yè)務(wù)邏輯， 同時(shí)在適當(dāng)?shù)臅r(shí)候?qū)Ω割愡M(jìn)行細(xì)化)
說了那么多，還是需要深刻的在代碼中多多運(yùn)用“面向接口編程”
OK，接下來是我們的代碼背景，還是不要上面的手機(jī)例子了， 老衲也是寫吐了哈哈- -，這次是英雄聯(lián)盟，恭喜RNG！
主角是咱們的Uzi和香鍋打野
首先聲明英雄和召喚師的接口
緊接著是咱們的兩個(gè)英雄低層接口
static class Xiazi implements IHero {@Overridepublic void attack() {System.out.println("瞎子，我用雙手，成就你的夢(mèng)想");} }static class VN implements IHero {@Overridepublic void attack() {System.out.println("VN，黑夜也會(huì)怕我");} }然后是咱們的上層player接口
static class ADPlayer implements IPlay {IHero hero;public ADPlayer(IHero hero) {this.hero = hero;}@Overridepublic void play() {hero.attack();} }static class AssistPlayer implements IPlay {IHero hero;public void setHero(IHero hero) {this.hero = hero;}@Overridepublic void play() {hero.attack();} }ok,接下來爽一把
這里注意，咱們的uzi使用構(gòu)造依賴注入方式，天生的AD，世界第一ADC
咱們的RNG圍繞下路戰(zhàn)術(shù)，所以香鍋就一個(gè)使命，保護(hù)下路，使用setter依賴注入
再次恭喜RNG集中賽冠軍，不知為何，老衲看小花生就是一臉不爽
接口隔離原則(Interface Splite Principle)
接口 隔離 其實(shí)從字面上就能很好的理解，先不看書，簡單從字面上理解一下這個(gè)原則接口：interface(Java 中interface關(guān)鍵字修飾，只能在其中聲明方法/接口和靜態(tài)變量)
類：class,對(duì)外提供的public方法，從外向內(nèi)看，這其實(shí)也是一種接口
隔離：隔離結(jié)合單一職責(zé)來看，隔離的基礎(chǔ)首先盡可能保證接口的定義符合單一職責(zé)原則，依據(jù)業(yè)務(wù)劃分出來的接口功能進(jìn)行進(jìn)一步進(jìn)行拆分細(xì)分，類不要去依賴那些他用不到的接口，不然沒有意義啊，依賴那么多搞什么，說白了就是對(duì)接口根據(jù)依賴關(guān)系進(jìn)行一波“抽取”的騷操作
定義
ok，山寨白話解釋完畢，下面來對(duì)下文檔，接口描述正確，我們就看一下隔離的解釋
- Clients should not be forced to depend upon interfaces that they don’t use.（客戶端不應(yīng)該依賴它不需要的接口。）
- The dependency of one class to another one should depend on the smallest possible interface.（類間的依賴關(guān)系應(yīng)該建立在最小的接口上。）
好吧，在下認(rèn)為這個(gè)解釋還不如白話來的直接明了，類間的依賴關(guān)系是什么？其實(shí)對(duì)于接口最直接的定義便是類之間進(jìn)行通信使用的，那么既然他們之間進(jìn)行通信，那么兩個(gè)類之間就存在了耦合關(guān)系，耦合達(dá)到最低要怎么做？就是盡量使這個(gè)耦合接口簡單明了，那么搬出書上的解釋：
建立單一接口，不要建立臃腫龐大的接口。再通俗一點(diǎn)講：接口盡量細(xì)化，同時(shí)接口中的方法盡量少
code
代碼背景還是咱們LOL，之前是hero，那今天就換成NPC吧
首先來兩個(gè)接口，分別是魔法攻擊和物理攻擊，也就是咱們的接口隔離
接下來是兩個(gè)咱們的法拉利和遠(yuǎn)程兵，分別實(shí)現(xiàn)魔法和物理攻擊接口
public static class YuanChenBing implements IMagicAttack {@Overridepublic void magicAttack() {System.out.println("遠(yuǎn)程兵，用魔法攻擊轟你家大燈");}}public static class FaLaLi implements IPhysicalAttack {@Overridepublic void physicalAttack() {System.out.println("法拉利炮車，用大炮物理攻擊轟你家大燈");} }最后登場的是大龍，大龍的話就比較囂張了，必須兩個(gè)攻擊的接口都實(shí)現(xiàn)
public static class DaLong implements IMagicAttack, IPhysicalAttack {@Overridepublic void magicAttack() {System.out.println("大龍向你吐了一口魔法濃痰");}@Overridepublic void physicalAttack() {System.out.println("大龍用尾巴懟你");} }接下來run一把瞅瞅
public static void main(String[] args) {DaLong daLong = new DaLong();daLong.magicAttack();daLong.physicalAttack();YuanChenBing yuanChenBing = new YuanChenBing();yuanChenBing.magicAttack();FaLaLi faLaLi = new FaLaLi();faLaLi.physicalAttack();}大龍向你吐了一口魔法濃痰 大龍用尾巴懟你 遠(yuǎn)程兵，用魔法攻擊轟你家大燈 法拉利炮車，用大炮物理攻擊轟你家大燈代碼擼完了，接下來搬出書上的總結(jié)，說的灰常準(zhǔn)確，請(qǐng)大家注意
-
接口要盡量小，根據(jù)接口隔離原則拆分接口時(shí)，首先必須滿足單一職責(zé)原則
-
接口要高內(nèi)聚，什么是高內(nèi)聚？高內(nèi)聚就是提高接口、類、模塊的處理能力，減少對(duì)外的交互
-
定制服務(wù)，一個(gè)系統(tǒng)或系統(tǒng)內(nèi)的模塊之間必然會(huì)有耦合，有耦合就要有相互訪問的接口（并不一定就是Java中定義的Interface，也可能是一個(gè)類或單純的數(shù)據(jù)交換），我們?cè)O(shè)計(jì)時(shí)就需要為各個(gè)訪問者（即客戶端）定制服務(wù)，什么是定制服務(wù)？定制服務(wù)就是單獨(dú)為一個(gè)個(gè)體提供優(yōu)良的服務(wù)
-
接口設(shè)計(jì)是有限度的，接口的設(shè)計(jì)粒度越小，系統(tǒng)越靈活，這是不爭的事實(shí)。但是，靈活的同時(shí)也帶來了結(jié)構(gòu)的復(fù)雜化，開發(fā)難度增加，可維護(hù)性降低，這不是一個(gè)項(xiàng)目或產(chǎn)品所期望看到的，所以接口設(shè)計(jì)一定要注意適度
-
一個(gè)接口只服務(wù)于一個(gè)子模塊或業(yè)務(wù)邏輯
-
通過業(yè)務(wù)邏輯壓縮接口中的public方法，接口時(shí)常去回顧，盡量讓接口達(dá)到“滿身筋骨肉”，而不是“肥嘟嘟”的一大堆方法
-
已經(jīng)被污染了的接口，盡量去修改，若變更的風(fēng)險(xiǎn)較大，則采用適配器模式進(jìn)行轉(zhuǎn)化處理
-
了解環(huán)境，拒絕盲從。每個(gè)項(xiàng)目或產(chǎn)品都有特定的環(huán)境因素，別看到大師是這樣做的你就照抄。千萬別，環(huán)境不同，接口拆分的標(biāo)準(zhǔn)就不同。深入了解業(yè)務(wù)邏輯
迪米特法則（Law of Demeter， LoD）
迪米特法則主要表達(dá)的是當(dāng)類與類之間產(chǎn)生耦合的情況下，類對(duì)外公布的方法將遵循怎樣的規(guī)則，其實(shí)說白了就是當(dāng)前類持有的耦合類，那么當(dāng)前類只關(guān)心自己要調(diào)用的方法，具體內(nèi)部有怎樣的實(shí)現(xiàn)則不關(guān)心，這些不關(guān)心的方法或者變量都與我無關(guān)，這樣寫有什么好處呢？相當(dāng)于以后當(dāng)實(shí)現(xiàn)邏輯發(fā)生了變化，但是結(jié)果不變，我們只需要更改耦合類的內(nèi)部實(shí)現(xiàn)即可，外部無需改動(dòng)，就是private,protect等修飾符的使用~
定義
一個(gè)對(duì)象應(yīng)該對(duì)其他對(duì)象有最少的了解。通俗地講，
一個(gè)類應(yīng)該對(duì)自己需要耦合或調(diào)用的類知道得最少，你（被耦合或調(diào)用的類）的內(nèi)部是如何復(fù)雜都和我沒關(guān)系，那是你的事情，我就知道你提供的這么多public方法，我就調(diào)用這么多，其他的我一概不關(guān)心。
類之間的低耦合要求：
- 類與類之間的關(guān)系是建立在類間的，而不是方法間，因此一個(gè)方法盡量不引入一個(gè)類中不存在的對(duì)象
- 迪米特法則要求類“羞澀”一點(diǎn)，盡量不要對(duì)外公布太多的public方法和非靜態(tài)的public變量，盡量內(nèi)斂，多使用private、package-private、protected等訪問權(quán)限
- 如果一個(gè)方法放在本類中，既不增加類間關(guān)系，也對(duì)本類不產(chǎn)生負(fù)面影響，那就放置在本類中
- 迪米特法則的核心觀念就是類間解耦，弱耦合，只有弱耦合了以后，類的復(fù)用率才可以提高。其要求的結(jié)果就是產(chǎn)生了大量的中轉(zhuǎn)或跳轉(zhuǎn)類，導(dǎo)致系統(tǒng)的復(fù)雜性提高，同時(shí)也為維護(hù)帶來了難度。讀者在采用迪米特法則時(shí)需要反復(fù)權(quán)衡，既做到讓結(jié)構(gòu)清晰，又做到高內(nèi)聚低耦合
code
慣例做一個(gè)代碼背景介紹
相信大家都聽說過five five open這位兄臺(tái)，那么咱們就以這位玩家作為咱們此次Demo的主角來編寫代碼
注意，不對(duì)此人自任何評(píng)判，純粹是講解需要，謝謝
首先咱們來一波接口，聲明GB該實(shí)現(xiàn)的方法，包括什么自動(dòng)攻擊啊，自動(dòng)躲避技能啊什么的
接下來就是咱們的RMB玩家需要持有的接口就比較簡單，遵循迪特米法則，就一個(gè)啟動(dòng)和停止
public interface IUseShell {void enableShell();void disableShell(); }然后是咱們的腳本實(shí)現(xiàn)類，此處同時(shí)實(shí)現(xiàn)RMB玩家的接口，簡單包裝一下，注意這里增加了一個(gè)內(nèi)部方法為計(jì)算躲避最佳路線，符合咱們迪特米法則，外部不關(guān)心內(nèi)部的實(shí)現(xiàn)邏輯
private static class ShellImpl implements IShellMethod, IUseShell {@Overridepublic void autoAttack() {System.out.println("auto attack hero or NPC");}@Overridepublic void stopAutoAttack() {System.out.println("stop auto attack");}@Overridepublic void autoDucking() {calculateDuckingPath();System.out.println("auto dodge attacks");}private void calculateDuckingPath() {System.out.println("calculate best ducking path!");}@Overridepublic void stopAutoDucking() {System.out.println("stop auto dodge attacks");}@Overridepublic void autoUseSkill() {System.out.println("auto use hero's skill");}@Overridepublic void stopAutoUseSkill() {System.out.println("stop auto use hero's skill");}@Overridepublic void autoChangeChangeEquipage() {System.out.println("auto buy best equipage");}@Overridepublic void stopAutoChangeChangeEquipage() {System.out.println("stop auto buy best equipage");}@Overridepublic void enableShell() {this.autoAttack();this.autoDucking();this.autoUseSkill();this.autoChangeChangeEquipage();}@Overridepublic void disableShell() {this.stopAutoAttack();this.stopAutoDucking();this.stopAutoUseSkill();this.stopAutoChangeChangeEquipage();} }最后則是我們用戶的包裝類，持有RMB接口對(duì)象即可
private static class ShellUser {private IUseShell useShell;public ShellUser() {useShell = new ShellImpl();}public void startGB() {System.out.println("開始上分");useShell.enableShell();}public void stopGB() {System.out.println("臥槽，對(duì)面要舉報(bào)我");useShell.disableShell();} }run一把爽一下
ShellUser lubenwei = new ShellUser(); lubenwei.startGB(); lubenwei.stopGB();... 開始上分 auto attack hero or NPC calculate best ducking path! auto dodge attacks auto use hero's skill auto buy best equipage 臥槽，對(duì)面要舉報(bào)我 stop auto attack stop auto dodge attacks stop auto use hero's skill stop auto buy best equipage好了，通過這個(gè)小Demo大家也可以大致輕松愉快的了解到迪特米法則，迪特米法則不同于上面說的幾個(gè)法則，更注重類間規(guī)范，是以后耦合類間的書寫規(guī)范，很多設(shè)計(jì)模式也是遵循的這些法則組合完成的設(shè)計(jì)。
開閉原則（Open-Closed Principle, OCP）
不管你是Java開發(fā)還是Android開發(fā)，只要你曾經(jīng)或者正在學(xué)習(xí)的路上，那么或多或少會(huì)在網(wǎng)上看到這樣的一句話:“對(duì)修改關(guān)閉，對(duì)擴(kuò)展開放”，OK， what is mean ?
定義
一個(gè)軟件實(shí)體應(yīng)該通過擴(kuò)展來實(shí)現(xiàn)變化，而不是通過修改已有的代碼來實(shí)現(xiàn)變化。軟件實(shí)體包括以下幾個(gè)部分：
- 項(xiàng)目或軟件產(chǎn)品中按照一定的邏輯規(guī)則劃分的模塊
- 抽象和類
- 方法
一個(gè)軟件產(chǎn)品只要在生命期內(nèi)，都會(huì)發(fā)生變化，既然變化是一個(gè)既定的事實(shí)，我們就應(yīng)該在設(shè)計(jì)時(shí)盡量適應(yīng)這些變化，以提高項(xiàng)目的穩(wěn)定性和靈活性，真正實(shí)現(xiàn)“擁抱變化”。
對(duì)于突如其來的變化，我們不是以修改原有代碼來適配新的變化，而是通過增寫擴(kuò)展的方式來應(yīng)對(duì)這個(gè)新變化。
書上為這些變化做了一個(gè)歸類，如下：
-
邏輯變化
只變化一個(gè)邏輯，而不涉及其他模塊，比如原有的一個(gè)算法是ab+c，現(xiàn)在需要修改為ab*c，可以通過修改原有類中的方法的方式來完成，前提條件是所有依賴或關(guān)聯(lián)類都按照相同的邏輯處理 -
子模塊變化
一個(gè)模塊變化，會(huì)對(duì)其他的模塊產(chǎn)生影響，特別是一個(gè)低層次的模塊變化必然引起高層模塊的變化，因此在通過擴(kuò)展完成變化時(shí)，高層次的模塊修改是必然的 -
可見視圖變化
注意:
在業(yè)務(wù)規(guī)則改變的情況下高層模塊必須有部分改變以適應(yīng)新業(yè)務(wù)，改變要盡量地少，防止變化風(fēng)險(xiǎn)的擴(kuò)散。開閉原則對(duì)擴(kuò)展開放，對(duì)修改關(guān)閉，并不意味著不做任何修改，低層模塊的變更，必然要有高層模塊進(jìn)行耦合，否則就是一個(gè)孤立無意義的代碼片段
項(xiàng)目開發(fā)、重構(gòu)、測試、投產(chǎn)、運(yùn)維，其中的重構(gòu)可以對(duì)原有的設(shè)計(jì)和代碼進(jìn)行修改，運(yùn)維盡量減少對(duì)原有代碼的修改，保持歷史代碼的純潔性，提高系統(tǒng)的穩(wěn)定性。
書中對(duì)開閉原則做了一個(gè)非常好的總結(jié)，這里就搬過來了：
開閉原則是最基礎(chǔ)的一個(gè)原則，前五章節(jié)介紹的原則都是開閉原則的具體形態(tài)，也就是說前五個(gè)原則就是指導(dǎo)設(shè)計(jì)的工具和方法，而開閉原則才是其精神領(lǐng)袖。換一個(gè)角度來理解，依照J(rèn)ava語言的稱謂，開閉原則是抽象類，其他五大原則是具體的實(shí)現(xiàn)類
那么開閉原則又會(huì)帶來哪些好處呢？
- 首先是“測試”，在擴(kuò)展的基礎(chǔ)上，測試只需要測試新增加的接口就可以，無需對(duì)之前已經(jīng)穩(wěn)定可靠的代碼進(jìn)行重復(fù)測試
- 通過縮小業(yè)務(wù)邏輯粒度從而達(dá)到代碼復(fù)用的作用，從原子邏輯組合成業(yè)務(wù)邏輯，那么原子的拼接組合自然而然能夠產(chǎn)生新的業(yè)務(wù)邏輯，復(fù)用的是久經(jīng)測試的穩(wěn)定代碼，效率得到很大提升
- 軟件更多的工作其實(shí)是在維護(hù)中，我們寫代碼的目的也是為了今后更好的迭代和維護(hù)來對(duì)代碼進(jìn)行架構(gòu)，那么在迭代的過程中，開發(fā)人員可以盡可能的少參與之前代碼的觀看和理解就能在原有的基礎(chǔ)上進(jìn)行功能的擴(kuò)展，那么這樣的代碼才是良性的代碼，相信同學(xué)們對(duì)閱讀之前的代碼也是或多或少的有過經(jīng)歷，能深刻體會(huì)其中“奧妙”。
- 代碼的設(shè)計(jì)并不能僅僅局限于當(dāng)前的需求，而是要考慮到將來的擴(kuò)展和可能的變化，預(yù)留出擴(kuò)展的余地
OK，說了這么多關(guān)于開閉原則的好處，那么接下來應(yīng)該提到的是開閉原則的使用。
老規(guī)矩，這次的code主角是王者榮耀游戲商城
public interface IGameHero {int getHeroPrice();int getDressUpPrice();String getName(); }怒上3個(gè)接口規(guī)定商城售賣英雄的行為，也是定義實(shí)體行為，分別是獲取英雄價(jià)格，獲取英雄皮膚價(jià)格，獲取英雄名字
然后是英雄接口實(shí)現(xiàn)類
public static class Hero implements IGameHero {private int mPrice;private int mDressPrice;private String mName;public Hero(int mPrice, int mDressPrice, String mName) {this.mPrice = mPrice;this.mDressPrice = mDressPrice;this.mName = mName;}@Overridepublic int getHeroPrice() {return mPrice;}@Overridepublic int getDressUpPrice() {return mDressPrice;}@Overridepublic String getName() {return mName;}@Overridepublic String toString() {return "英雄:" + getName() + "\t英雄價(jià)格:" + getHeroPrice() + "\t皮膚價(jià)格:" + getDressUpPrice();} }接下來上商店邏輯類，這里就簡單寫下，通俗易懂
public static class GameStore {private List<IGameHero> heroes;public GameStore() {this.heroes = new ArrayList<>();heroes.add(new Hero(13888, 888, "白起"));heroes.add(new Hero(10888, 388, "莊周"));heroes.add(new Hero(13888, 288, "程咬金"));heroes.add(new Hero(18888, 688, "貂蟬"));}public List<IGameHero> getHeroes() {return heroes;} }意思通俗易懂，大家自行參閱這些中文式代碼哈~
然后就是我們的main咯~
這就是完美的構(gòu)建了我們的某榮耀的簡單商城了
好了，接下來TX要出活動(dòng)了，刺激消費(fèi)，掙一波，咋整
很簡單，針對(duì)咱們的擴(kuò)展開放原則，新建一個(gè)英雄實(shí)現(xiàn)接口類
其實(shí)也就是集成原有的英雄類，增加一個(gè)折扣屬性，重寫獲取英雄價(jià)格和皮膚價(jià)格
然后再略微動(dòng)一下商城類，增加商城類的方法，這一步也是不可避免的，上層增加實(shí)體的獲取和實(shí)現(xiàn)這些代碼是必須要寫的。
增加兩個(gè)方法，折扣為88折，你買不了吃虧，買不了上當(dāng)~
然后在main里面進(jìn)行調(diào)用
顯而易見，很輕松的就達(dá)到了折扣的目的，這就是所謂的抽象原則的擁抱開放，關(guān)閉修改
總結(jié)
以上是生活随笔為你收集整理的设计原则——设计模式基础的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 快收藏了！优秀的Linux工程师必备的8
- 下一篇： 任正非：到底什么样的人才能当干部