Android架构演进 · 设计模式· 为什么建议你一定要学透设计模式？
一、引言
Hello，我是小木箱，歡迎來到小木箱成長營Android架構(gòu)演進(jìn)系列教程，今天將分享Android架構(gòu)演進(jìn) · 設(shè)計(jì)模式· 為什么建議你一定要學(xué)透設(shè)計(jì)模式？
今天分享的內(nèi)容主要分為四部分內(nèi)容，第一部分是設(shè)計(jì)模式5W2H，第二部分是7大設(shè)計(jì)原則，第三部分是3大設(shè)計(jì)模式，最后一部分是總結(jié)與展望。
其中，7大設(shè)計(jì)原則主要包括開閉原則、里氏替換原則、依賴倒置原則、單一職責(zé)原則、接口隔離原則、最小知識原則和合成復(fù)用原則。3大設(shè)計(jì)模式主要包括創(chuàng)建型、結(jié)構(gòu)型和行為型。
拿破侖之前說過Every French soldier carries a marshal’s baton in his knapsack，意思是“每個(gè)士兵背包里都應(yīng)該裝有元帥的權(quán)杖”，本意是激勵每一名上戰(zhàn)場的士兵都要有大局觀，有元帥的思維。
編程的海洋里也是如此，不想當(dāng)架構(gòu)師的程序員不是好程序員，我覺得架構(gòu)師可能是大部分程序員最理想的歸宿。而設(shè)計(jì)模式是每一個(gè)架構(gòu)師所必備的技能之一，只有學(xué)透了設(shè)計(jì)模式，才敢說真正理解了軟件工程。
希望每個(gè)有技術(shù)追求的Android開發(fā)，可以從代碼中去尋找屬于自己的那份快樂，通過代碼構(gòu)建編程生涯的架構(gòu)思維。
如果學(xué)完小木箱Android架構(gòu)演進(jìn)設(shè)計(jì)模式系列文章，那么任何人都能為社區(qū)或企業(yè)貢獻(xiàn)優(yōu)質(zhì)的SDK設(shè)計(jì)方案。
二、設(shè)計(jì)模式5W2H
5W2H又叫七何分析法，5W2H是二戰(zhàn)的時(shí)候，美國陸軍兵器修理部發(fā)明的思維方法論，便于啟發(fā)性的理解深水區(qū)知識。5W2H是What、Who、Why、Where、When、How much、How首字母縮寫之和，廣泛用于企業(yè)技術(shù)管理、頭腦風(fēng)暴等。小木箱今天嘗試用5W2H分析法分析一定要學(xué)透設(shè)計(jì)模式底層邏輯。
2.1 What： 什么是設(shè)計(jì)模式？
首先聊聊設(shè)計(jì)模式5W2H的What， 什么是設(shè)計(jì)模式？sourcemaking曾經(jīng)提過，在軟件工程中，設(shè)計(jì)模式是軟件設(shè)計(jì)中，常見問題的可重復(fù)解決方案。設(shè)計(jì)模式雖然不可以直接轉(zhuǎn)換為代碼，然后完成設(shè)計(jì)。但是設(shè)計(jì)模式是解決不同情況特定共性問題的通用模板。
不管北京的四合院、廣州的小蠻腰還是上海的東方明珠，都有好的建筑地基。設(shè)計(jì)模式也是如此，設(shè)計(jì)模式是高效能工程建設(shè)基石，如果業(yè)務(wù)代碼看作鋼筋水泥，那么設(shè)計(jì)模式可以看作是建筑地基。只有地基足夠牢固，項(xiàng)目工程才不會因?yàn)橘|(zhì)量問題爛尾。
如果想高度重用代碼，那么建議你一定要學(xué)透設(shè)計(jì)模式。
如果想讓代碼更容易被理解，那么建議你一定要學(xué)透設(shè)計(jì)模式。
如果想確保代碼可靠性、可維護(hù)性，那么建議你一定要學(xué)透設(shè)計(jì)模式。
簡而言之，設(shè)計(jì)模式不僅是被多數(shù)人知曉、被反復(fù)驗(yàn)證的代碼設(shè)計(jì)經(jīng)驗(yàn)總結(jié)，而且設(shè)計(jì)模式是特定場景和業(yè)務(wù)痛點(diǎn)，針對同類問題通用解決方案。
2.2 Who： 誰應(yīng)該學(xué)透設(shè)計(jì)模式？
聊完設(shè)計(jì)模式5W2H的What，再聊聊設(shè)計(jì)模式5W2H的Who，誰應(yīng)該學(xué)透設(shè)計(jì)模式？ 設(shè)計(jì)模式可以用于所有項(xiàng)目開發(fā)工作的一種高價(jià)值設(shè)計(jì)理念，而且在寫源代碼或者閱讀源代碼中經(jīng)常需要用到。
如果你的工作是偏架構(gòu)方向，那么使用設(shè)計(jì)模式可能像一日三餐一樣頻繁。設(shè)計(jì)模式既然鏈接著每個(gè)基礎(chǔ)模塊的方方面面，就看你想不想讓你的編程生涯走的更遠(yuǎn)，如果想，就接著往下面看。
設(shè)計(jì)模式不是代碼! 設(shè)計(jì)模式不是代碼! 設(shè)計(jì)模式不是代碼!?重要的事情說三遍，設(shè)計(jì)模式是編程思想。如果參加外企面試，那么基本不會像國內(nèi)考各種八股文，有兩個(gè)重點(diǎn)考查項(xiàng)目，一方面是算法，另一方面是系統(tǒng)設(shè)計(jì)。而系統(tǒng)設(shè)計(jì)和設(shè)計(jì)模式息息相關(guān)。
如果面試國內(nèi)中大廠架構(gòu)組也是，設(shè)計(jì)模式對于架構(gòu)組程序員而言，基本隨便拿捏，設(shè)計(jì)模式是區(qū)分中級程序員和高級程序員的關(guān)鍵。當(dāng)國內(nèi)Android程序員疲于業(yè)務(wù)，導(dǎo)致設(shè)計(jì)模式在業(yè)務(wù)方面缺少實(shí)踐，如果你掌握的比他們更好，是不是相比之下會更有競爭力。學(xué)透設(shè)計(jì)模式是普通開發(fā)逆襲架構(gòu)師的捷徑，但凡有一定工作年限的Android開發(fā)，都必須學(xué)透設(shè)計(jì)模式。
2.3 Why： 為什么要學(xué)透設(shè)計(jì)模式？
聊完設(shè)計(jì)模式5W2H的Who，再聊聊設(shè)計(jì)模式5W2H的Why，為什么要學(xué)透設(shè)計(jì)模式？ 關(guān)于為什么要學(xué)透設(shè)計(jì)模式的原因一共有三點(diǎn)。
第一，學(xué)透設(shè)計(jì)模式，為職場晉升打開綠色通道。?代碼是程序員的一個(gè)門面。有些互聯(lián)網(wǎng)大廠技術(shù)崗晉升，會隨機(jī)抽取對方代碼提交節(jié)點(diǎn)，根據(jù)對方的代碼片段，進(jìn)行review并給予晉升打分。這是平時(shí)為什么要注重代碼整潔性很重要原因。學(xué)透了設(shè)計(jì)模式并應(yīng)用于項(xiàng)目開發(fā)，等同你有了職場晉升直升飛機(jī)。
第二，學(xué)透設(shè)計(jì)模式，編碼全局觀更強(qiáng)。?正確使用設(shè)計(jì)模式，無異于站在巨人的肩膀上看世界。前輩們在 Java 、C++等語言領(lǐng)域上，花費(fèi)幾十年時(shí)間，并經(jīng)過分類、提煉、總結(jié)、沉淀和驗(yàn)證等各個(gè)方面的努力，才整理了一套精品架構(gòu)思想，如果想成為一名Senior Android Dev，那么有什么理由不去研究呢？
第三，學(xué)透設(shè)計(jì)模式，抽象建模能力更強(qiáng)。?對于特定場景和特定業(yè)務(wù)，如果正確的使用設(shè)計(jì)模式，那么代碼質(zhì)量和業(yè)務(wù)拓展性會有質(zhì)的飛躍。
2.4 When： 什么時(shí)候使用設(shè)計(jì)模式？
說完設(shè)計(jì)模式5W2H的Who，再聊聊設(shè)計(jì)模式5W2H的When，關(guān)于使用設(shè)計(jì)模式的時(shí)機(jī)一共有兩點(diǎn)。
第一點(diǎn)，場景要吻合
第二點(diǎn)，確保原有業(yè)務(wù)穩(wěn)定基礎(chǔ)上，套用或靈活運(yùn)用設(shè)計(jì)模式，可以解決未來可能出現(xiàn)的拓展性和維護(hù)性問題。
2.5 Where： 哪些地方需要使用到設(shè)計(jì)模式？
說完設(shè)計(jì)模式5W2H的When，再聊聊設(shè)計(jì)模式5W2H的Where，哪些地方需要使用到設(shè)計(jì)模式？多數(shù)情況下，如果程序員做技術(shù)需求要考慮其靈活性的地方，就可以使用設(shè)計(jì)模式。22種設(shè)計(jì)模式都有自己的策閱，22種設(shè)計(jì)模式的策閱也適合不同的場景。
我們不可能從策閱設(shè)計(jì)模式的業(yè)務(wù)背景套用狀態(tài)設(shè)計(jì)模式的業(yè)務(wù)背景，好比女朋友，世界上沒有性格一模一樣的女生，一個(gè)女生只能解決當(dāng)時(shí)狀態(tài)的情感需要。我們的前任和現(xiàn)任帶給的體感都不完全一樣。因此，每一種設(shè)計(jì)模式中的策閱和女朋友一樣，每一個(gè)都是原創(chuàng)。
設(shè)計(jì)模式和女朋友有一個(gè)共同特征就是提供了當(dāng)時(shí)背景下可以解決問題(情緒價(jià)值)的結(jié)構(gòu)。在解決實(shí)際問題時(shí)，必須考慮該問題解決方案的變動，如果業(yè)務(wù)發(fā)生大的變動，那么需要考慮設(shè)計(jì)模式是否通用。好比女朋友，如果當(dāng)下你習(xí)慣內(nèi)卷，但女朋友突然躺平了，那么后面話題可能越來越少。
使用設(shè)計(jì)模式切勿生搬硬套，正確的使用設(shè)計(jì)模式可以很好地將技術(shù)需求映射業(yè)務(wù)模型上。但是如果過度使用不合適的設(shè)計(jì)模式會造成程序可讀性更高，維護(hù)成本變得更高。好比女朋友，如果為了女朋友過度忍讓，那么最終可能因?yàn)殛P(guān)系不平等不歡而散。
那么，怎樣挑選合適的設(shè)計(jì)模式呢?使用設(shè)計(jì)模式的準(zhǔn)則是在建立對設(shè)計(jì)模式有很好認(rèn)知前提，并習(xí)慣這種方法模型，看到一種特定的技術(shù)背景，就立馬可以聯(lián)想到具體對應(yīng)的模型。這種地方使用設(shè)計(jì)模式是最合適不過的。好比追女生，如果能對方興趣愛好和性格特征能相互吸引，各方面背景匹配度高，會更合適一點(diǎn)。
綜上所述，如果你發(fā)現(xiàn)特定業(yè)務(wù)痛點(diǎn)，剛好符合特定設(shè)計(jì)原則，或能匹配特定設(shè)計(jì)模式方法模型，那么建議你將這種業(yè)務(wù)抽象成通用模板映射到實(shí)際業(yè)務(wù)里。
2.6 How much： 學(xué)透設(shè)計(jì)模式的價(jià)值點(diǎn)是什么？
說完設(shè)計(jì)模式5W2H的Where，再聊聊設(shè)計(jì)模式5W2H的How much，學(xué)透設(shè)計(jì)模式的價(jià)值點(diǎn)是什么？關(guān)于使用設(shè)計(jì)模式的價(jià)值一共有三點(diǎn)，第一點(diǎn)是針對個(gè)人，第二點(diǎn)是針對工程質(zhì)量，最后一點(diǎn)是針對團(tuán)隊(duì)。
對個(gè)人而言，正確使用設(shè)計(jì)模式可以提高程序代碼設(shè)計(jì)能力和職場受歡迎度。
對工程質(zhì)量而言，如果想要代碼高可用、高復(fù)用、可讀性強(qiáng)和擴(kuò)展性強(qiáng)，那么需要設(shè)計(jì)模式做支撐。
對團(tuán)隊(duì)而言，在現(xiàn)有工業(yè)化和商業(yè)化的代碼設(shè)計(jì)維度上，設(shè)計(jì)模式不僅更標(biāo)準(zhǔn)和更工程化，而且設(shè)計(jì)模式可以提高編碼開發(fā)效率，節(jié)約解決問題時(shí)間。
2.7 How： 怎樣學(xué)透設(shè)計(jì)模式？
說完設(shè)計(jì)模式5W2H的How much，再聊聊設(shè)計(jì)模式5W2H的How，怎樣學(xué)透設(shè)計(jì)模式？學(xué)透設(shè)計(jì)模式有四種途徑，分別是網(wǎng)課、文章、書籍、源碼和項(xiàng)目實(shí)戰(zhàn)。網(wǎng)課方面，小木箱推薦大家在B站看一下馬士兵教育和圖靈課堂視頻。這兩門課程可以帶大家很輕松的入門設(shè)計(jì)模式。
文章方面，小木箱推薦大家看一下百度工程師教你玩轉(zhuǎn)設(shè)計(jì)模式（觀察者模式）、?提升代碼質(zhì)量的方法：領(lǐng)域模型、設(shè)計(jì)原則、設(shè)計(jì)模式、洞察設(shè)計(jì)模式的底層邏輯、設(shè)計(jì)模式二三事、設(shè)計(jì)模式在業(yè)務(wù)系統(tǒng)中的應(yīng)用、Android中竟然包含這么多設(shè)計(jì)模式，一起來學(xué)一波！、當(dāng)設(shè)計(jì)模式遇上 Hooks、談?wù)勎夜ぷ髦械?3個(gè)設(shè)計(jì)模式和設(shè)計(jì)模式之美等文章。
書籍方面，小木箱推薦大家看一下《head first》?、《重學(xué)Java設(shè)計(jì)模式 RPC中間件設(shè)計(jì)應(yīng)用程序設(shè)計(jì)編程實(shí)戰(zhàn)分布式領(lǐng)域驅(qū)動設(shè)計(jì)和設(shè)計(jì)模式結(jié)合》?和?《代碼整潔之道》?。
源碼方面，Glog日志框架可以值得一學(xué)。
項(xiàng)目實(shí)戰(zhàn)方面，學(xué)有余力的同學(xué)可以動手用設(shè)計(jì)模式實(shí)現(xiàn)一下定位組件、實(shí)時(shí)日志組件和啟動監(jiān)控組件。
最后，聽說有個(gè)叫小木箱這個(gè)家伙設(shè)計(jì)模式的文章寫的還挺不錯的，可以關(guān)注一下~
三、7大設(shè)計(jì)原則
產(chǎn)生代碼差的原因，有兩方面，第一方面是外部原因，第二方面是內(nèi)部原因。外部原因主要有：項(xiàng)目排期急，沒有多少時(shí)間去設(shè)計(jì)；資源短缺，人手不夠，只能怎么快怎么來；緊急問題修復(fù)，臨時(shí)方案快速處理……。內(nèi)部原因主要有：自我要求不高；無反饋通道
而解決代碼差的根因主要是方法有三個(gè)：領(lǐng)域建模、設(shè)計(jì)原則、設(shè)計(jì)模式
分析階段：當(dāng)拿到一個(gè)需求時(shí)，先不要著急想著怎么把這個(gè)功能實(shí)現(xiàn)，這種很容易陷入事務(wù)腳本的模式。
舉個(gè)上面進(jìn)店Tab展示的例子，它有兩個(gè)關(guān)鍵的實(shí)體：導(dǎo)航欄、Tab，其中導(dǎo)航欄里面包含了若干個(gè)Tab。
設(shè)計(jì)階段：分析完了有哪些實(shí)體后，再分析職責(zé)如何分配到具體的實(shí)體上，這就要運(yùn)用一些設(shè)計(jì)原則去指導(dǎo)
回到上面的例子上，Tab的職責(zé)主要有兩個(gè)：一個(gè)是Tab能否展示，這是它自己的職責(zé)，如上新Tab展示的邏輯是店鋪30天內(nèi)有上架新商品；
另一個(gè)職責(zé)就是Tab規(guī)格信息的構(gòu)建，也是它自己要負(fù)責(zé)的。
導(dǎo)航欄的職責(zé)有兩個(gè)：一個(gè)是接受Tab注冊；另一個(gè)是展示。職責(zé)分配不合理，也就不滿足高內(nèi)聚、低耦合的特征。
打磨階段：這個(gè)階段選擇合適的模式去實(shí)現(xiàn)，大家一看到模式都會理解它是做什么的，比如看到模板類，就會知道處理通用的業(yè)務(wù)流程，具體變化的部分放在子類中處理。
上面的這個(gè)例子，用到了2個(gè)設(shè)計(jì)模式：一個(gè)是訂閱者模式，Tab自動注冊的過程；另一個(gè)是模板模式，先判斷Tab能否展示，然后再構(gòu)建Tab規(guī)格信息，流程雖然簡單，也可以抽象出來通用的流程出來，子類只用簡單地重寫2個(gè)方法。
領(lǐng)域模型主要是和產(chǎn)品和運(yùn)營梳理業(yè)務(wù)模型，進(jìn)行流程化優(yōu)化，進(jìn)而判斷需求是否合理可行。
提升代碼質(zhì)量還有一個(gè)捷徑，那就是要遵循七大原則，七大原則好比毛澤東農(nóng)村包圍城市指導(dǎo)方針。首先確定統(tǒng)一中國目標(biāo)，然后是在統(tǒng)治力量薄弱的農(nóng)村建立革命根據(jù)地，等革命隊(duì)伍變大，建立農(nóng)村包圍城市的矩陣，最后采取不同摧毀策閱對國民政府不同城市政權(quán)進(jìn)行各個(gè)擊破。
如果系統(tǒng)工程業(yè)務(wù)代碼混亂，我們首先確保底層代碼功能不變，然后以點(diǎn)成線，以線成面，以面成網(wǎng)，以網(wǎng)建模。根據(jù)設(shè)計(jì)原則，針對不同的業(yè)務(wù)痛點(diǎn)，制定單一原則或組合原則技術(shù)方案。接著小步快跑，穩(wěn)定安全地實(shí)施軟件工程質(zhì)量改造規(guī)劃，最終達(dá)到降低業(yè)務(wù)冗余或者降低未來大幅度代碼變更帶來的風(fēng)險(xiǎn)目的。設(shè)計(jì)原則的底層邏輯就是讓軟件能夠較好地應(yīng)對變化，降本增效。
而設(shè)計(jì)原則又分為七個(gè)部分，分別是開閉原則、里式替換原則、依賴倒置原則、接口隔離原則、最小知識原則、單一職責(zé)原則和合成復(fù)用原則。
3.1 開閉原則
第一個(gè)設(shè)計(jì)原則是開閉原則，開閉原則簡稱OCP，正如英文定義的那樣the open–closed principle，?Entities should be open for extension， but closed for modification?，?對擴(kuò)展開放，對修改關(guān)閉。
這樣做的目的是保護(hù)已有代碼的穩(wěn)定性、復(fù)用性、靈活性、維護(hù)性和可擴(kuò)展性，同時(shí)又讓系統(tǒng)更具有彈性。
Android需求發(fā)生變化的時(shí)候，不提倡直接修改Android基類源代碼，盡量擴(kuò)展模塊或者擴(kuò)展原有的功能，去實(shí)現(xiàn)新需求變更。
關(guān)于開閉原則，一般采用繼承或?qū)崿F(xiàn)的方式，比如： 如果涉及到非通用功能，不要把業(yè)務(wù)邏輯加到BaseActvity，而是單獨(dú)使用ChildActvity類繼承abstract BaseActvity，并讓ChildActvity去拓展abstract BaseActvity的抽象方法。
翻一翻開源庫源碼，面向抽象類或面向接口去實(shí)現(xiàn)的功能場景非常常見。
那么，為什么要使用開閉原則呢？
第一，開閉原則可以降低功能設(shè)計(jì)成本
第二，開閉原則可以提高代碼穩(wěn)定性
第三，開閉原則可以提高代碼可維護(hù)性
第四，開閉原則可以降低測試的成本
因?yàn)闊o論是大佬還是小白改動工程陳舊代碼塊，都無法保證改完后代碼是0風(fēng)險(xiǎn)的。因此，如果遵守開閉原則，那么可以極大限度的降低變更引發(fā)的歷史功能性缺失、邏輯漏洞等風(fēng)險(xiǎn)。
3.1.1 UML圖例
老爸幫小明去買書，書有很多特征，一種特征是書是有名字的，一種特征是書是有價(jià)格的，那如果按照開閉原則的話，首先要定義一個(gè)IBook接口，描述書的兩種特征:名稱、價(jià)格。
然后用一個(gè)類NovelBook去實(shí)現(xiàn)這個(gè)接口，方便讀取和修改書的名稱和價(jià)格。
根據(jù)開閉原則，使用者如果要對書進(jìn)行比如打折降價(jià)活動是不能直接在NovelBook操作的，需要用DisNovelBook繼承NovelBook去拓展NovelBook的getName和getPrice方法。
3.1.2 Bad Code
//----------------------------代碼片段一----------------------------/*** 功能描述： 定義小說類NovelBook-實(shí)現(xiàn)類*/ public class NovelBook implements IBook {public String name;public int price;public NovelBook(String name， int price) {this.name = name;this.price = price;}@Overridepublic String getName() {return this.name;}@Overridepublic int getPrice() {if (this.price > 50) {return (int) (this.price * 0.9);} else {return this.price;}} } //----------------------------代碼片段二---------------------------- /**** 功能描述： 現(xiàn)在有個(gè)書店售書的場景，首先定義一個(gè)IBook類，里面有兩個(gè)屬性:名稱、價(jià)格。*/ public interface IBook{public String getName();public int getPrice(); } //----------------------------代碼片段三---------------------------- public class Client {public static void main(String[] args) {NovelBook novel = new NovelBook("笑傲江湖"， 100);System.out.println("書籍名字：" + novel.getName() + "書籍價(jià)格：" + novel.getPrice());} } 復(fù)制代碼3.1.3 Good Code
因?yàn)槿绻磥硇枨笞兏?#xff0c;如小明要買數(shù)學(xué)書和化學(xué)書，其中化學(xué)書價(jià)格不能超過15元，數(shù)學(xué)不能高于30元，且數(shù)學(xué)書可以使用人教版，而化學(xué)書既可以使用湘教版也可以使用人教版。
//----------------------------代碼片段一----------------------------/*** 功能描述： 定義小說類NovelBook-實(shí)現(xiàn)類*/ public class NovelBook implements IBook {public String name;public int price;public NovelBook(String name， int price) {this.name = name;this.price = price;}@Overridepublic String getName() {return this.name;}@Overridepublic int getPrice() {return this.price;} } //----------------------------代碼片段二----------------------------public class DisNovelBook extends NovelBook {public DisNovelBook(String name， int price) {super(name， price);}// 復(fù)寫價(jià)格方法，當(dāng)價(jià)格大于50，就打9析@Overridepublic int getPrice() {if (this.price > 50) {return (int) (this.price * 0.9);} else {return this.price;}} }//----------------------------代碼片段三---------------------------- /**** 功能描述： 現(xiàn)在有個(gè)書店售書的場景，首先定義一個(gè)IBook類，里面有兩個(gè)屬性:名稱、價(jià)格。*/ public interface IBook{public String getName();public int getPrice(); }//----------------------------代碼片段四---------------------------- public class Client{public static void main(String[] args){IBook disnovel = new DisNovelBook ("小木箱成長營"，100000);System.out.println("公眾號名字："+disnovel .getName()+"公眾號粉絲數(shù)量："+disnovel .getPrice());} } 復(fù)制代碼這些邏輯加在一塊的話，因?yàn)橘徺I條件不一樣，需要將不變的邏輯抽象成接口實(shí)現(xiàn)類NovelBook，但如果不使用開辟原則，直接更改接口實(shí)現(xiàn)類NovelBook，隨著需求不斷膨脹，但凡多增加一些控制項(xiàng)，在多人協(xié)同開發(fā)過程中代碼維護(hù)風(fēng)險(xiǎn)度會越來越高。
3.1.4 使用原則
開辟原則使用原則有2個(gè)點(diǎn)，第一個(gè)點(diǎn)是抽象約束;第二個(gè)點(diǎn)是封裝變化
首先來說一說抽象約束，抽象約束一共有三個(gè)方面，第一個(gè)方面是接口或抽象類的方法全部要public，方便去使用。
第二個(gè)方面是參數(shù)類型、引用對象盡量使用接口或者抽象類，而不是實(shí)現(xiàn)類；因?yàn)槭褂媒涌诤统橄箢惪梢员苊庹J(rèn)為更改起始數(shù)據(jù)；
第三點(diǎn)是抽象層盡量保持穩(wěn)定，一旦確定即不允許修改。如果抽象層經(jīng)常變更，會導(dǎo)致所有實(shí)現(xiàn)類報(bào)錯。
接著來說一說封裝變化，封裝變化一共有兩個(gè)方面，第一個(gè)方面是相同的邏輯要抽象到一個(gè)接口或抽象類中。
第二個(gè)方面是將不同的變化封裝到不同的接口或抽象類中，不應(yīng)該有兩個(gè)不同的變化出現(xiàn)在同一個(gè)接口或抽象類中。
比如上文說的，如果老爸買完書了，準(zhǔn)備買菜，那么要單獨(dú)立一個(gè)IVegetable的接口。而不是改造原來的IBook。
3.2 里氏替換原則
第二個(gè)設(shè)計(jì)原則是里氏替換原則，里氏替換原則簡稱LSP，正如英文定義的那樣The Liskov Substitution Principle，Functions that use pointers of references to base classes must be able to use objects of derived classes without knowing it 。
子類可以替換父類，子類對象能夠替換程序中父類對象出現(xiàn)的任何地方，并且保證原來程序的邏輯行為不變以及正確性不會被破壞。
相當(dāng)于子類可以擴(kuò)展父類功能。繼承是里氏替換原則的重要表現(xiàn)方式。里氏替換原則用來指導(dǎo)繼承關(guān)系中子類該如何設(shè)計(jì)的。
里氏替換原則，注意事項(xiàng)是盡量不要重寫父類的方法，也是開閉原則的重要方式之一，為什么不建議重寫父類的方法呢？
因?yàn)橹貙憰采w父類的功能，導(dǎo)致使用者對類預(yù)期功能被修改后得到就不是對方想要的功能。
提出問題
下面有個(gè)關(guān)于Bird鳥類位移時(shí)間的技術(shù)需求：
已知Bird(基類)的子類Swallow(小燕子)和Ostrich(鴕鳥)位移了300米，Ostrich(鴕鳥)的跑步速度為120米/秒。
Swallow(小燕子)和Ostrich(鴕鳥)的飛行速度為120米/秒和0米/秒，求Swallow(小燕子)和Ostrich(鴕鳥)的位移時(shí)間。
分析問題
位移時(shí)間，算的是位移距離/跑步速度還是位移距離/飛行速度呢？
Ostrich(鴕鳥)能飛嗎？
Swallow(小燕子)飛行速度能否單獨(dú)抽象成一個(gè)方法呢？
解決問題
可以參考UML圖例、Good Code、Bad Code和里氏替換使用原則。
3.2.1 UML圖例
3.2.2 Bad Code
常規(guī)方式?： 定義鳥的基類Bird，Bird(基類)有一個(gè)setFlySpeed(飛翔速度)。根據(jù)distance(距離)去算出它飛翔的getFlyTime(飛翔時(shí)間)。
//----------------------------代碼片段一---------------------------- public class Bird {private double flySpeed;public void setFlySpeed(double speed) {this.flySpeed = speed;}public double getFlyTime(double distance) {return distance / flySpeed;} }//----------------------------代碼片段二---------------------------- public class Swallow extends Bird {} //----------------------------代碼片段三---------------------------- public class Ostrich extends Bird{@Overridepublic void setFlySpeed(double speed) {speed = 0;} } //----------------------------代碼片段四---------------------------- public class Main {public static void main(String[] args) {Bird swallow = new Swallow();Bird ostrich = new Ostrich();swallow.setFlySpeed(120);ostrich.setFlySpeed(120);System.out.println("小木箱說，如果飛行300公里：");try {System.out.println("燕子將飛行： " + swallow.getFlyTime(300) + "小時(shí)。"); // 燕子飛行2.5小時(shí)。System.out.println("鴕鳥將飛行： " + ostrich.getFlyTime(300) + "小時(shí)。"); // 鴕鳥將飛行Infinity小時(shí)。} catch (Exception err) {System.out.println("發(fā)生錯誤了！");}} } 復(fù)制代碼Bird(基類)有兩個(gè)子類，一個(gè)是Swallow(小燕子)，一個(gè)是Ostrich(鴕鳥)。
小燕子只要設(shè)置正確的setFlySpeed(速度)和distance(距離)即可。
但Ostrich(鴕鳥)不太一樣，Ostrich(鴕鳥)是不會飛的，Ostrich(鴕鳥)只會地上跑。
因?yàn)镺strich(鴕鳥)沒有flySpeed(飛翔速度)。那在構(gòu)造Ostrich(鴕鳥)，去繼承實(shí)現(xiàn)這 Bird(基類)， Ostrich(鴕鳥)的重寫方法setFlySpeed(設(shè)置飛翔速度)傳0.0。
在Bird(基類) 當(dāng)中去計(jì)算getFlyTime(飛翔時(shí)間)，按照常規(guī)的應(yīng)該distance(距離) / setFlySpeed(設(shè)置飛翔速度)，就得到了getFlyTime(飛翔時(shí)間)。
去調(diào)用getFlyTime(飛翔時(shí)間) 時(shí)間的時(shí)候，因?yàn)閷strich(鴕鳥) 的getFlyTime(飛翔時(shí)間)的子類的參數(shù)speed，重寫了setFlySpeed(設(shè)置飛翔速度)方法，并設(shè)置該方法speed參數(shù)為0，數(shù)學(xué)里面0不能作為分母，所以會得到一個(gè)無效結(jié)果Infinity，重寫過程，違背了里氏替換原則。
結(jié)果:
3.2.3 Good Code
正確的方式是??：打斷Ostrich(鴕鳥)和Bird(基類)繼承關(guān)系，定義Bird(基類)和Ostrich(鴕鳥)的超級父類Animal(動物)，讓Animal(動物)有奔跑能力。Ostrich(鴕鳥)的飛行速度雖然為 0，但奔跑速度不為 0，可以計(jì)算出其奔跑 300 千米所要花費(fèi)的時(shí)間。
那么，雖然不能將Ostrich(鴕鳥)的getRunTime(位移時(shí)間)抽象成 Bird(基類)的 getFlyTime(飛翔時(shí)間)。
但可以利用超級父類Animal(動物)的getRunTime(位移時(shí)間)，即花費(fèi)時(shí)長，這時(shí)Ostrich(鴕鳥)的setRunSpeed(跑步速度)就不為0，因?yàn)镺strich(鴕鳥)復(fù)用了超級父類Animal(動物) getRunTime(位移時(shí)間)功能。
超級父類Animal(動物)有一個(gè) getRunSpeed(跑步速度) ，而不是Bird(基類)的setFlySpeed那個(gè)飛翔速度。
去設(shè)置setRunSpeed(跑步速度) 之后。因?yàn)槲灰剖莿游锏奶煨浴ｘB類和鴕鳥都具備位移能力。
所以可以在超級父類Animal(動物) 的基礎(chǔ)上，定義Bird(基類) 子類，去繼承 Animal(動物) ，把Animal(動物)的一些能力轉(zhuǎn)化成Bird(基類) 相關(guān)一些能力，這樣就和預(yù)期需求是一致的了。
//----------------------------代碼片段一---------------------------- public class Bird extends Animal {private double flySpeed;public void setFlySpeed(double speed) {this.flySpeed = speed;}public double getFlyTime(double distance) {return distance / flySpeed;} } //----------------------------代碼片段二---------------------------- public class Animal {private double runSpeed;public double getRunTime(double distance) {return distance / speed;}public void setRunSpeed(double speed) {this.runSpeed = speed;}} //----------------------------代碼片段三---------------------------- public class Swallow extends Bird {}//----------------------------代碼片段四---------------------------- public class Ostrich extends Animal{} //----------------------------代碼片段五---------------------------- public class Main {public static void main(String[] args) {Bird swallow = new Swallow();Animal ostrich = new Ostrich();swallow.setFlySpeed(120);ostrich.setRunSpeed(120);System.out.println("如果飛行300公里：");try {System.out.println("燕子將位移： " + swallow.getFlyTime(300) + "小時(shí)。"); System.out.println("鴕鳥將位移： " + ostrich.getRunTime(300) + "小時(shí)。"); } catch (Exception err) {System.out.println("發(fā)生錯誤了！");}} } 復(fù)制代碼結(jié)果:
3.2.4 使用原則
Java中，多態(tài)是不是違背了里氏替換原則？
那么，JAVA中，多態(tài)是不是違背了里氏替換原則呢？如果extends的目的是為了多態(tài)，而多態(tài)的前提就是Swallow(子類)覆蓋并重新定義Bird(基類)的getFlySpeed()。
為了符合LSP，應(yīng)該將Bird(基類)定義為abstract，并定義getFlySpeed()(抽象方法)，讓Swallow(子類)重新定義getFlySpeed()。
當(dāng)父類是abstract時(shí)，Bird(基類)就是不能實(shí)例化，所以也不存在可實(shí)例化的Bird(基類)對象在程序里。
//----------------------------代碼片段一---------------------------- public abstract class Bird{protected abstract double getFlySpeed();public double getFlyTime(double distance){return distance / getFlySpeed();}}//----------------------------代碼片段二----------------------------public class Swallow extends Bird{protected double getFlySpeed(){return 100.0;}} 復(fù)制代碼里氏替換原則和開閉原則的區(qū)別有哪些？
里氏替換原則和開閉原則的區(qū)別在于： 開閉原則大部分是面向接口編程，少部分是針對繼承的，而里氏替換原則主要針對繼承的，降低繼承帶來的復(fù)雜度
什么時(shí)候使用里氏替換原則？
使用里氏替換原則的時(shí)機(jī)有兩個(gè)，第一個(gè)是重新提取公共部分的方法，第二個(gè)是改變繼承關(guān)系.
首先，重新提取公共部分的方法主要是把公共部分提取出來作為一個(gè)抽象基類.
而提取公共部分的時(shí)機(jī)是代碼不是很多的時(shí)候應(yīng)用，提取得部分可以作為一個(gè)設(shè)計(jì)工具.
然后，改變繼承關(guān)系主要是從父子關(guān)系變?yōu)槲申P(guān)系或兄弟關(guān)系，可以把它們的一些公有特性提取到一個(gè)抽象接口，再分別實(shí)現(xiàn).具體可以看 #3.2.1 UML圖例
3.3 依賴倒置原則
第三個(gè)設(shè)計(jì)原則是里氏替換原則，里氏替換原則簡稱DIP，正如英文定義的那樣Dependence Inversion Principle，Abstractions should not depend on details. Details should depend on abstractions，抽象不依賴于細(xì)節(jié)，而細(xì)節(jié)依賴于抽象。高層模塊不能直接依賴低層模塊，而是通過接口或抽象的方式去實(shí)現(xiàn)。
從定義也就可以看出來，依賴倒置原則是為了降低類或模塊的耦合性，提倡面向接口編程，能降低工程維護(hù)成本，降低由于類或?qū)崿F(xiàn)發(fā)生變化帶來的修改成本，提高代碼穩(wěn)定性。
比如小木箱在組件化設(shè)計(jì)當(dāng)中，會員模塊、訂單模塊和用戶模塊不應(yīng)該直接依賴基礎(chǔ)平臺組件數(shù)據(jù)庫、網(wǎng)絡(luò)和統(tǒng)計(jì)組件等。
而應(yīng)該從會員模塊、訂單模塊和用戶模塊抽取BaseModule和中間件等模塊，橫向依賴基礎(chǔ)平臺組件BaseModule和中間件，去實(shí)現(xiàn)模塊與模塊之間的一些訪問與跳轉(zhuǎn)，這樣層級才會更清晰。
依賴倒置原則核心思想是面向接口編程，因?yàn)槿绻嫦驅(qū)崿F(xiàn)類，實(shí)現(xiàn)類如果發(fā)生變化，那么依賴實(shí)現(xiàn)類的實(shí)現(xiàn)方法和功能都會產(chǎn)生蝴蝶效應(yīng)。
提出問題
小木箱剛拿到駕照，準(zhǔn)備在電動車、新能源、汽油車三類型進(jìn)行購車，于是拿沃爾沃、寶馬、特斯拉進(jìn)行測試，請用代碼讓這三輛汽車自動跑起來？
分析問題
如果小木箱想把跑起來的自動駕駛代碼，復(fù)用給其他駕駛者，代碼的健壯性如何？
解決問題
可以參考UML圖例、Good Code、Bad Code和思考復(fù)盤。
3.3.1 UML圖例
3.3.2 Bad Code
下面代碼比較劣質(zhì)的原因在于自動駕駛能力與駕駛者高耦合度，如果想讓其他駕駛者使用自動駕駛系列的車，那么駕駛者必須將車型實(shí)例重新傳給其他駕駛者，沒有做到真正意義上的插拔式注冊，換個(gè)駕駛者就不成立了。
//----------------------------代碼片段一---------------------------- public class BMW {public void autoRun() {System.out.println("BMW is running!");} } //----------------------------代碼片段二---------------------------- public class Tesla {public void autoRun() {System.out.println("Tesla is running!");} } //----------------------------代碼片段三---------------------------- public class Volvo {public void autoRun() {System.out.println("Volvo is running!");} } //----------------------------代碼片段四---------------------------- public class AutoDriver {public void autoDrive(Tesla tesla) {tesla.autoRun();}public void autoDrive(BMW bm) {bm.autoRun();}public void autoDrive(Volvo volvo) {volvo.autoRun();}} //----------------------------代碼片段四---------------------------- public class Main {public static void main(String[] args) {Tesla tesla = new Tesla();BMW bm = new BMW();Volvo volvo = new Volvo();AutoDriver driver = new AutoDriver();driver.autoDrive(tesla);driver.autoDrive(bm);driver.autoDrive(volvo);} } 復(fù)制代碼結(jié)果:
3.3.3 Good Code
那么，正確實(shí)現(xiàn)方式是怎樣的呢？ 首先要定義一個(gè)自動駕駛接口IAutoDriver。因?yàn)樽詣玉{駛，新能源比如說像寶馬、特斯拉、沃爾沃都有實(shí)現(xiàn)自動駕駛能力。
但是比如說像紅旗、長城不是一個(gè)自動駕駛的實(shí)現(xiàn)者。
那對自動駕駛接口IAutoDriver，如果你有自動駕駛能力，那么你就去實(shí)現(xiàn)IAutoDriver，去重寫autoDrive(自動駕駛)的能力。否則，就不實(shí)現(xiàn)自動駕駛IAutoDriver接口。
對 AutoDriver 的話，駕駛者是去通過依賴倒置原則，把寶馬、特斯拉、沃爾沃自動駕駛模式接口IAutoCar傳進(jìn)來，通過autoRun開啟自動駕駛模式。
autoRun是區(qū)分了自動駕駛還是普通駕駛模式。具體的代碼方式很簡單，首先 new一個(gè)寶馬實(shí)例，然后去實(shí)現(xiàn)自動駕駛接口 IAutoCar，最后把寶馬實(shí)例傳給 AutoDriver，實(shí)現(xiàn)自動駕駛的方式，特斯拉、沃爾沃也是這樣的。
對于自動駕駛技術(shù)，不關(guān)心駕駛的什么車，寶馬、特斯拉、沃爾沃還是大眾，只關(guān)心你是實(shí)現(xiàn)了IAutoDriver接口。只關(guān)心你是否有autoDrive(自動駕駛)能力。
如果有自動駕駛能力，使用者就直接調(diào)用autoDrive(自動駕駛)能力。具體的怎么實(shí)現(xiàn)呢？是AutoDriver的實(shí)現(xiàn)類IAutoDriver決定的，這便是依賴倒置原則，不依賴具體的實(shí)現(xiàn)，只調(diào)IAutoCar接口方法選擇自動駕駛模式autoRun即可.
//----------------------------代碼片段一---------------------------- public interface IAutoCar {public void autoRun(); } //----------------------------代碼片段二---------------------------- public class BMW implements IAutoCar{@Overridepublic void autoRun() {System.out.println("BMW is running!");} } //----------------------------代碼片段三---------------------------- public class Tesla implements IAutoCar {@Overridepublic void autoRun() {System.out.println("Tesla is running!");} } //----------------------------代碼片段四---------------------------- public class Volvo implements IAutoCar{@Overridepublic void autoRun() {System.out.println("Volvo is running!");} }//----------------------------代碼片段五---------------------------- public interface IAutoDriver {public void autoDrive(IAutoCar car); } //----------------------------代碼片段六---------------------------- public class AutoDriver implements IAutoDriver{@Overridepublic void autoDrive(IAutoCar car) {car.autoRun();} } //----------------------------代碼片段六---------------------------- public class Main {public static void main(String[] args) {IAutoDriver driver = new AutoDriver();driver.autoDrive(new Tesla());driver.autoDrive(new BMW());driver.autoDrive(new Volvo());} } 復(fù)制代碼結(jié)果:
3.3.4 使用原則
在簡單工廠設(shè)計(jì)模式和策略設(shè)計(jì)模式，都是使用依賴倒置原則進(jìn)行注入，不過簡單工廠設(shè)計(jì)模式， 使用的是接口方法注入， 而策略設(shè)計(jì)模式使用的是構(gòu)造函數(shù)注入，這一塊后文詳細(xì)介紹。
3.4 單一職責(zé)原則
第四個(gè)設(shè)計(jì)原則是單一職責(zé)原則，單一職責(zé)原則簡稱SRP， 正如英文The Single Responsibility Principle定義的那樣，A class should have one， and only one， reason to change。
單一職責(zé)指的是一個(gè)類只能因?yàn)橐粋€(gè)理由被修改，一個(gè)類只做一件事。不要設(shè)計(jì)大而全的類，要設(shè)計(jì)粒度小、功能單一的類。
類的職能要有界限。單一原則要求類要高內(nèi)聚，低耦合。意思是為了規(guī)避代碼冗余，無關(guān)職責(zé)、無關(guān)功能的方法和對象不要引入類里面。
因?yàn)槿绻粋€(gè)類承擔(dān)的職責(zé)過多，就等于把這些職責(zé)耦合在一起，一個(gè)職責(zé)的變化可能會削弱或者抑制這個(gè)類完成其他職責(zé)的能力。
這種耦合會導(dǎo)致脆弱他的設(shè)計(jì)，當(dāng)變化發(fā)生時(shí)，設(shè)計(jì)會遭受到意想不到的破壞；軟件設(shè)計(jì)真正要做的許多內(nèi)容就是發(fā)現(xiàn)職責(zé)并把那些職責(zé)相互分離。
比如去銀行取錢，取錢的類不應(yīng)該包含打印發(fā)票，取錢的類只管取錢動作，打印發(fā)票功能，需要新建類完成。目的是降低類的復(fù)雜度，提高閱讀性，降低代碼變更造成的風(fēng)險(xiǎn)。
再比如Android里面Activity過于臃腫會讓感覺很頭大，MVP、MVVM、MVP和MVI等架構(gòu)都是為了讓Activity變得職責(zé)單一。
提出問題:
老師去網(wǎng)上采購“ 三國演義 ”、“ 紅樓夢 ”、“ 三國演義 ”、“ 西游記 ”各一本。
已知“ 紅樓夢 ”50元/本，“ 三國演義 ”40元/本，“ 西游記 ”30元/本，“ 水滸傳 ”20元/本。
如果“ 紅樓夢 ” 8 折促銷，“ 西游記 ”6 折促銷，根據(jù)書的價(jià)格，求所有圖書的總價(jià)格。
分析問題:
如果采購1000本書籍，單品折扣策閱可能不一樣，如果單品價(jià)格隨著單品購買數(shù)量變化，那么購物車價(jià)格條件一旦變化，購物車代碼會因此膨脹，進(jìn)而影響代碼可維護(hù)性，如何解決這種問題?
3.4.1 UML圖例
3.4.2 Bad Code
這段壞味道的代碼問題就在于: 購物車摻雜了價(jià)格計(jì)算功能，購物車正常只關(guān)心對商品的CRUD能力，如果有一天，價(jià)格計(jì)算方式改變，那這里就需要動購物車代碼，購物車變更會引起方法變動，從而帶來風(fēng)險(xiǎn)。
//----------------------------代碼片段一---------------------------- public class WoodBook {private String name;private double price;public WoodBook(String name， double price) {this.name = name;this.price = price;}public String getName() {return name;}public double getPrice() {return price;} } //----------------------------代碼片段二----------------------------public class ShoppingCart { private List<WoodBook> list = new ArrayList<>(); public void addBook(WoodBook book) {list.add(book);}public double checkOut() {double total = 0;for (WoodBook book : list) {if ("紅樓夢".equals(book.getName())) {total = total + book.getPrice() * 0.8;} else if ("西游記".equals(book.getName())) {total = total + book.getPrice() * 0.6;} else {total = total + book.getPrice();}}return total;} } //----------------------------代碼片段三---------------------------- public class Main {public static void main(String[] args) {ShoppingCart shoppingCart = new ShoppingCart();shoppingCart.addBook(new WoodBook("紅樓夢"，50));shoppingCart.addBook(new WoodBook("三國演義"，40));shoppingCart.addBook(new WoodBook("西游記"，30));shoppingCart.addBook(new WoodBook("水滸傳"，20));double total = shoppingCart.checkOut();System.out.println("所有圖書價(jià)格為："+total);} } 復(fù)制代碼3.4.3 Good Code
正確的方式: 首先計(jì)算價(jià)格的邏輯，交給接口實(shí)現(xiàn)，購物車只關(guān)心價(jià)格計(jì)算的結(jié)果，并將結(jié)果返回即可。然后計(jì)算價(jià)格接口交給調(diào)用方實(shí)現(xiàn)，使用者不關(guān)心紅樓夢和西游記價(jià)格折扣策閱還是0折扣策閱，最后需求如果發(fā)生變更，那么只需要更改調(diào)用方實(shí)現(xiàn)邏輯即可。
//----------------------------代碼片段一----------------------------public class WoodBook {private String name;private double price;public WoodBook(String name， double price) {this.name = name;this.price = price;}public String getName() {return name;}public double getPrice() {return price;} } //----------------------------代碼片段二---------------------------- public class DefaultDiscountStrategy implements DiscountStrategy {@Overridepublic double discount(List<WoodBook> list) {double total = 0;for (WoodBook book : list) {total = total + book.getPrice();}return total;} } //----------------------------代碼片段三---------------------------- public class SingleDiscountStrategy implements DiscountStrategy {@Overridepublic double discount(List<WoodBook> list) {double total = 0;for (WoodBook book : list) {if ("西游記".equals(book.getName())) {total = total + book.getPrice() * 0.6;} else if ("紅樓夢".equals(book.getName().toString())) {total = total + book.getPrice() * 0.8;}else {total = total + book.getPrice() ;}}return total;} } //----------------------------代碼片段四---------------------------- public class ShoppingCart {private List<WoodBook> list = new ArrayList<>();private DiscountStrategy discountStrategy;public void addBook(WoodBook book) {list.add(book);}public void setDiscountStrategy(DiscountStrategy discountStrategy) {this.discountStrategy = discountStrategy;}public double checkOut() {if (discountStrategy == null) {discountStrategy = new DefaultDiscountStrategy();}return discountStrategy.discount(list);} } //----------------------------代碼片段五---------------------------- public interface DiscountStrategy {double discount(List<WoodBook> list); } //----------------------------代碼片段六---------------------------- public class Main {public static void main(String[] args) {ShoppingCart shoppingCart = new ShoppingCart();shoppingCart.addBook(new WoodBook("紅樓夢"，50));shoppingCart.addBook(new WoodBook("三國演義"，40));shoppingCart.addBook(new WoodBook("西游記"，30));shoppingCart.addBook(new WoodBook("水滸傳"，20));shoppingCart.setDiscountStrategy(new SingleDiscountStrategy());double total = shoppingCart.checkOut();System.out.println("所有圖書價(jià)格為："+total);} } 復(fù)制代碼結(jié)果:
3.4.4 思考復(fù)盤
關(guān)于單一職責(zé)原則我們有四個(gè)問題需要思考
問題一: 如何判斷類的職責(zé)是否足夠單一？
判斷類的職責(zé)是否足夠單一有五條規(guī)則:
規(guī)則一: 如果類中的代碼行數(shù)、函數(shù)或?qū)傩赃^多，會影響代碼的可讀性和可維護(hù)性，那么我們就需要考慮對類進(jìn)行拆分；
規(guī)則二: 如果類依賴的其他類過多，或者依賴類的其他類過多，不符合高內(nèi)聚、低耦合的設(shè)計(jì)思想，那么我們就需要考慮對類進(jìn)行拆分；
規(guī)則三: 如果私有方法過多，我們就要考慮能否將私有方法獨(dú)立到新的類中，那么我們就設(shè)置為 public 方法，供更多的類使用，從而提高代碼的復(fù)用性；
規(guī)則四: 如果比較難給類起一個(gè)合適名字，很難用一個(gè)業(yè)務(wù)名詞概括，或者只能用一些籠統(tǒng)的Manager、Context 之類的詞語來命名，那么這就說明類的職責(zé)定義得可能不夠清晰
規(guī)則五: 如果類中大量的方法都是集中操作類中的某幾個(gè)屬性，比如: 在 UserInfo 例子中，如果一半的方法都是在操作 address 信息，那么可以考慮將這幾個(gè)屬性和對應(yīng)的方法拆分出來
問題二: 類的職責(zé)是否設(shè)計(jì)得越單一越好？
類的職責(zé)單一性標(biāo)準(zhǔn)有四方面。
第一方面，單一職責(zé)原則通過避免設(shè)計(jì)大而全的類，避免將不相關(guān)的功能耦合在一起，來提高類的內(nèi)聚性。
第二方面，類職責(zé)單一，類依賴的和被依賴的其他類也會變少，減少了代碼的耦合性，以此來實(shí)現(xiàn)代碼的高內(nèi)聚、低耦合。
第三方面，如果拆分得過細(xì)，實(shí)際上會適得其反，反倒會降低內(nèi)聚性，也會影響代碼的可維護(hù)性。
第四方面，根據(jù)不同的場景對某個(gè)類或模塊單一職責(zé)的判斷是不同的，不能為了拆分而拆分，造成過度設(shè)計(jì)，難以維護(hù)。
問題三: 單一職責(zé)原則為什么要這么設(shè)計(jì)？
那么單一職責(zé)原則為什么要這么設(shè)計(jì)?因?yàn)槿绻粋€(gè)類承擔(dān)的職責(zé)過多，即耦合性太高一個(gè)職責(zé)的變化可能會影響到其他的職責(zé)。
問題四: Hook違背了單一職責(zé)原則嗎？
那么，Hook違背了單一職責(zé)原則嗎？Hook突破了Java層OOP系統(tǒng)層設(shè)計(jì)理念，也就違背了單一職責(zé)原則。Hook雖好，不建議廣泛使用，因?yàn)樵陂_發(fā)過程中可能導(dǎo)致依賴不清晰、命名沖突、來源不清晰等問題。
3.5 接口隔離原則
第五個(gè)原則是接口隔離原則，接口隔離原則指的是接口隔離原則是指客戶端不應(yīng)該依賴于它不需要的接口。接口隔離原則簡稱ISP，正如英文定義的那樣interface-segregation principle，Clients should not be forced to depend upon interfaces that they do not use. 客戶端不應(yīng)該被強(qiáng)迫依賴它不需要的接口。其中的 “客戶端”，可以理解為接口的調(diào)用者或者使用者。
接口隔離原則是盡量將臃腫龐大的接口顆粒度拆得更細(xì)。和單一原則類似，一個(gè)接口，涵蓋的職責(zé)實(shí)現(xiàn)的功能盡量簡單單一，只跟接口自身想實(shí)現(xiàn)的功能相關(guān)，不能把別人干的活也涵蓋進(jìn)來，讓實(shí)現(xiàn)者只關(guān)心接口獨(dú)立單元方法。
我在架構(gòu)組設(shè)計(jì)對外的 API 或?qū)ν饽芰?#xff0c;接口干的職責(zé)，要非常明確的，接口不能做與接口無關(guān)工作或隱藏邏輯，一個(gè)類對一個(gè)類依賴應(yīng)建立在最小接口依賴基礎(chǔ)之上。
提出問題
小木箱是一名AndroidDev也是一名DevopsDev，請用代碼分類打印標(biāo)記小木箱的技能樹。
分析問題
首先將技能樹全部存放到技能清單IDev，然后讓AndroidDev和DevopsDev分別實(shí)現(xiàn)技能清單IDev，最后在AndroidDev和DevopsDev匹配的技能樹打印標(biāo)記。
解決問題
可以參考UML圖例、Good Code、Bad Code和接口隔離使用原則。
3.5.1 UML圖例
3.5.2 Bad Code
比如小木箱做了AndroidDev和DevopsDev兩份簡歷，而AndroidDev簡歷和DevopsDev簡歷所具備的技術(shù)棧又各不相同，但歸檔在小木箱同一份IDev技能樹清單里面。
如果小木箱把AndroidDev簡歷和DevopsDev簡歷實(shí)現(xiàn)技能樹清單接口，那么勢必會導(dǎo)致AndroidDev簡歷既有Devops簡歷也有AndroidDev技能樹，DevopsDev簡歷既有DevopsDev技能樹也有AndroidDev技能樹。
如果有一天小木箱技能樹清單接口技能發(fā)生相應(yīng)的變化，那么很容易給兩份簡歷帶來一些風(fēng)險(xiǎn)和改變。
//--------------------------------代碼塊一--------------------------------- public interface IDev {void framework();void ci2cd();void jetpack();void java(); } //--------------------------------------代碼塊二--------------------------------------- public class AndroidDev implements IDev{@Overridepublic void framework() {System.out.println("CrazyCodingBoy is a Android developer and he knows framework");}@Overridepublic void ci2cd() {}@Overridepublic void jetpack() {System.out.println("CrazyCodingBoy is a Android developer and he knows jetpack");}@Overridepublic void java() {System.out.println("CrazyCodingBoy is a Android developer and he knows java");} } //--------------------------------------代碼塊三--------------------------------------- public class DevopsDev implements IDev {@Overridepublic void framework() {}@Overridepublic void ci2cd() {System.out.println("CrazyCodingBoy is a Devops developer and he knows CI and CD");}@Overridepublic void jetpack() {}@Overridepublic void java() {System.out.println("CrazyCodingBoy is a Devops developer and he knows java");} } //--------------------------------------代碼塊四--------------------------------------- public class Main {public static void main(String[] args) {AndroidDev androidDev = new AndroidDev();DevopsDev devopsDev = new DevopsDev();androidDev.framework();androidDev.jetpack();devopsDev.ci2cd();androidDev.java();devopsDev.java();// TODO: delete 無效空實(shí)現(xiàn) androidDev.ci2cd(); devopsDev.framework();devopsDev.jetpack();} 復(fù)制代碼結(jié)果:
3.5.3 Good Code
接口隔離原則是把臃腫龐大的IDev技能樹清單接口，拆分成力度更小的ICi2cd、IFramework、IJetpack和IJava接口，提高整個(gè)系統(tǒng)和接口的一個(gè)靈活性和可維護(hù)性，同時(shí)提高整個(gè)系統(tǒng)內(nèi)聚性，減少對外交互。
ICi2cd只關(guān)心小木箱CI/CD的研發(fā)能力，誰想持有這個(gè)能力就交給誰去實(shí)現(xiàn)，不同的技能樹，交給不同的去完成自己的能力。
否則，IDev接口功能發(fā)生變化，就得去改AndroidDev和DevopsDev的邏輯。
如果代碼臃腫，代碼量大，那么容易手抖或改了不該改的，造成線上事故。
如果通過接口或模塊隔離方式實(shí)現(xiàn)，那么就可以降低修改成本。
//--------------------------------代碼塊一--------------------------------- public interface ICi2cd {void ci2cd(); } //--------------------------------------代碼塊二--------------------------------------- public interface IFramework {void framework(); } //--------------------------------------代碼塊三--------------------------------------- public interface IJetpack {void jetpack(); } //--------------------------------------代碼塊四--------------------------------------- public interface IJava {void java(); } //--------------------------------------代碼塊五--------------------------------------- public class AndroidDev implements IFramework ， IJetpack ， IJava {@Overridepublic void framework() {System.out.println("CrazyCodingBoy is a Android developer and he knows framework");}@Overridepublic void jetpack() {System.out.println("CrazyCodingBoy is a Android developer and he knows jetpack");}@Overridepublic void java() {System.out.println("CrazyCodingBoy is a Android developer and he knows java");} }//--------------------------------------代碼塊六--------------------------------------- public class DevopsDev implements ICi2cd ， IJava {@Overridepublic void ci2cd() {System.out.println("CrazyCodingBoy is a Devops developer and he knows CI and CD");}@Overridepublic void java() {System.out.println("CrazyCodingBoy is a Devops developer and he knows java");} } //--------------------------------------代碼塊七--------------------------------------- public class Main { public static void main(String[] args) {AndroidDev androidDev = new AndroidDev();DevopsDev devopsDev = new DevopsDev();androidDev.framework();androidDev.jetpack();androidDev.java();devopsDev.ci2cd();devopsDev.java();} } 復(fù)制代碼結(jié)果:
3.5.4 思考復(fù)盤
接著我們聊聊思考復(fù)盤，思考復(fù)盤分為兩方面，第一方面是接口隔離原則和單一職責(zé)原則的區(qū)別?第二方面接口隔離原則優(yōu)點(diǎn)。
接口隔離原則和單一職責(zé)原則的區(qū)別?
接口隔離原則和單一職責(zé)原則的區(qū)別有兩個(gè)，第一，單一職責(zé)原則指的是類、接口和方法的職責(zé)是單一的，強(qiáng)調(diào)的是職責(zé)，也就是說在一個(gè)接口里，只要職責(zé)是單一的，有10個(gè)方法也是可以的。
第二，接口隔離原則指的是在接口中的方法盡量越來越少，接口隔離原則的前提必須先符合單一職責(zé)，在單一職責(zé)的前提下，接口盡量是單一接口。
接口隔離原則優(yōu)點(diǎn)
接口隔離原則優(yōu)點(diǎn)有三個(gè)。
第一，隱藏實(shí)現(xiàn)細(xì)節(jié)
第二，降低耦合性
第三，提高代碼的可讀性
3.6 最小知識原則
第六個(gè)設(shè)計(jì)原則是最小知識原則，最小知識原則簡稱LOD，正如英文定義的那樣Law of Demeter
，a module should not have knowledge of the inner details of the objects it manipulates?。不該有直接依賴關(guān)系的類，不要有依賴；
有依賴關(guān)系的類之間，盡量只依賴必要的接口。最小知識原則是希望減少類之間的耦合，讓類越獨(dú)立越好，每個(gè)類都應(yīng)該少了解系統(tǒng)的其他部分，一旦發(fā)生變化，需要了解這一變化的類就會比較少。
最小知識原則和單一職責(zé)的目的都是實(shí)現(xiàn)高內(nèi)聚低耦合，但是出發(fā)的角度不一樣，單一職責(zé)是從自身提供的功能出發(fā)，最小知識原則是從關(guān)系出發(fā)。
提出問題
如果我們把一個(gè)對象看作是一個(gè)人，那么要實(shí)現(xiàn)“一個(gè)人應(yīng)該對其他人有最少的了解”，做到兩點(diǎn)就足夠了： 第一點(diǎn)，只和直接的朋友交流； 第二點(diǎn)，減少對朋友的了解。下面就詳細(xì)說說如何做到這兩點(diǎn)。
最小知識原則還有一個(gè)英文解釋是：talk only to your immediate friends（只和直接的朋友交流）。
分析問題
什么是朋友呢？每個(gè)對象都必然會與其他的對象有耦合關(guān)系，兩個(gè)對象之間的耦合就會成為朋友關(guān)系。
那么什么又是直接的朋友呢？出現(xiàn)在成員變量、方法的輸入輸出參數(shù)中的類就是直接的朋友。最小知識原則要求只和直接的朋友通信。
解決問題
可以參考UML圖例、Good Code、Bad Code和最小知識原則使用原則。
3.6.1 UML圖例
3.6.2 Bad Code
很簡單的例子：老師讓班長清點(diǎn)全班同學(xué)的人數(shù)。這個(gè)例子中總共有三個(gè)類：老師Teacher、班長GroupLeader和學(xué)生Student。
在這個(gè)例子中，我們的Teacher有幾個(gè)朋友？兩個(gè)，一個(gè)是GroupLeader，它是Teacher的command()方法的入?yún)?#xff1b;另一個(gè)是Student，因?yàn)樵赥eacher的command()方法體中使用了Student。
那么Teacher有幾個(gè)是直接的朋友？按照直接的朋友的定義
出現(xiàn)在成員變量、方法的輸入輸出參數(shù)中的類就是直接的朋友
只有GroupLeader是Teacher的直接的朋友。
Teacher在command()方法中創(chuàng)建了Student的數(shù)組，和非直接的朋友Student發(fā)生了交流，所以，上述例子違反了最小知識原則。
方法是類的一個(gè)行為，類竟然不知道自己的行為與其他的類產(chǎn)生了依賴關(guān)系，這是不允許的，嚴(yán)重違反了最小知識原則！
//--------------------------------------代碼塊一--------------------------------------- public interface IStudent { } //--------------------------------------代碼塊二--------------------------------------- public class Student implements IStudent {} //--------------------------------------代碼塊三--------------------------------------- public interface IGroupLeader {void count(List<Student> students); }//--------------------------------------代碼塊四--------------------------------------- public interface IGroupLeader {void count(List<Student> students); } //--------------------------------------代碼塊五--------------------------------------- public class GroupLeader implements IGroupLeader{@Overridepublic void count(List<Student> students) {System.out.println("The number of students attending the class is: " + students.size());} } //--------------------------------------代碼塊六--------------------------------------- public interface ITeacher {void command(IGroupLeader groupLeader); } //--------------------------------------代碼塊七--------------------------------------- public class Teacher implements ITeacher{@Overridepublic void command(IGroupLeader groupLeader) {List<Student> allStudent = new ArrayList<>();allStudent.add(new Student());allStudent.add(new Student());allStudent.add(new Student());allStudent.add(new Student());allStudent.add(new Student());groupLeader.count(allStudent);} } //--------------------------------------代碼塊八--------------------------------------- public class Main {public static void main(String[] args) {ITeacher teacher = new Teacher();teacher.command(new GroupLeader());} } 復(fù)制代碼結(jié)果:
3.6.3 Good Code
我們打斷學(xué)生和GroupLeader聯(lián)系，直接的聯(lián)系每個(gè)類都只和直接的朋友交流，有效減少了類之間的耦合
//--------------------------------------代碼塊一--------------------------------------- public interface IStudent { } //--------------------------------------代碼塊二--------------------------------------- public class Student implements IStudent {} //--------------------------------------代碼塊三--------------------------------------- public interface IGroupLeader {void count(); } //--------------------------------------代碼塊四--------------------------------------- public class GroupLeader implements IGroupLeader {private List<Student> students;public GroupLeader(List<Student> students) {this.students = students;}@Overridepublic void count() {System.out.println("The number of students attending the class is: " + students.size());} } //--------------------------------------代碼塊五--------------------------------------- public interface ITeacher {void command(IGroupLeader groupLeader); } //--------------------------------------代碼塊六--------------------------------------- public class Teacher implements ITeacher {@Overridepublic void command(IGroupLeader groupLeader) {groupLeader.count();} } //--------------------------------------代碼塊七--------------------------------------- public class Main {public static void main(String[] args) {ITeacher teacher = new Teacher();List<Student> allStudent = new ArrayList(4);allStudent.add(new Student());allStudent.add(new Student());allStudent.add(new Student());allStudent.add(new Student());teacher.command(new GroupLeader(allStudent));} } 復(fù)制代碼結(jié)果:
3.6.4 使用原則
最少知識原則的使用原則有6個(gè)。
第一，在類的劃分上，應(yīng)當(dāng)創(chuàng)建弱耦合的類，類與類之間的耦合越弱，就越有利于實(shí)現(xiàn)可復(fù)用的目標(biāo)。 第二，在類的結(jié)構(gòu)設(shè)計(jì)上，每個(gè)類都應(yīng)該降低成員的訪問權(quán)限。 第三，在類的設(shè)計(jì)上，只要有可能，一個(gè)類應(yīng)當(dāng)設(shè)計(jì)成不變的類。 第四，在對其他類的引用上，一個(gè)對象對其他類的對象的引用應(yīng)該降到最低。 第五，盡量限制局部變量的有效范圍，降低類的訪問權(quán)限。
第六，謹(jǐn)慎使用Serializable。
3.7 合成復(fù)用原則
最后一個(gè)原則是合成復(fù)用原則。合成復(fù)用原則簡稱CARP，正如英文定義的那樣Composite/Aggregate Reuse Principle，?try to use composite/aggregate *，?*合成復(fù)用原則要求我們在軟件設(shè)計(jì)的過程中，盡量不要通過繼承方式實(shí)現(xiàn)功能和類的一些組合。
因?yàn)樵?Java 只支持單繼承的， C 、 C ++支持多繼承。所以設(shè)計(jì)模式在 Java 這一塊的規(guī)范，它是不提倡繼承來解決問題的，所以更提倡是合成復(fù)用，一個(gè)類持有另外一個(gè)對象，把能力交給另外的對象去完成。
因?yàn)槔^承破壞了會繼承復(fù)用的和破壞類的一個(gè)封裝性，子類和父類耦合度會比較大，因此推薦使用合成復(fù)用原則
最小知識原則，如果因?yàn)槭侄?#xff0c;可能會不小心改了父類，最小知識原則限制復(fù)用靈活性，合成復(fù)用原則可以維持類的封裝性，降低類與類的耦合度，提高功能的靈活性。
合成復(fù)用原則可以將已知的對象和成員變量納入新的對象和成員變量，方法里邊去調(diào)用成員變量的具體的功能。就達(dá)成了一個(gè)合成復(fù)用原則。
3.7.1 UML圖例
3.7.2 Bad Code
汽車從能源的角度來說，分為電動車ETCar和汽油車PCar。
電動車ETCar和汽油車PCar有很多顏色，如: 白色、紅色。
如果后期新增黃色，那么需要電動車ETCar和汽油車PCar去繼承Car，并讓紅色車RedPCar和白色車WhiteETCar去繼承電動車ETCar和汽油車PCar。繼承的方式可以實(shí)現(xiàn)類組合，但缺點(diǎn)是顏色和車型組合越多，類組合會呈N 倍遞，導(dǎo)致類爆炸。
//--------------------------------------代碼塊一--------------------------------------- public abstract class Car {public abstract void move(); } //--------------------------------------代碼塊二--------------------------------------- public abstract class ETCar extends Car{ } //--------------------------------------代碼塊三--------------------------------------- public abstract class PCar extends Car { } //--------------------------------------代碼塊四--------------------------------------- public class RedETCar extends Car{@Overridepublic void move() {System.out.println("Red ETCar is running!");} } //--------------------------------------代碼塊五--------------------------------------- public class RedPCar extends PCar {@Overridepublic void move() {System.out.println("Red PCar is running!");} } //--------------------------------------代碼塊六--------------------------------------- public class WhiteETCar extends ETCar {@Overridepublic void move() {System.out.println("White ETCar is running!");} } //--------------------------------------代碼塊七--------------------------------------- public class WhitePCar extends PCar {@Overridepublic void move() {System.out.println("White PCar is running!");} } //--------------------------------------代碼塊八--------------------------------------- public class Main {public static void main(String[] args) {new RedETCar().move();new RedPCar().move();new WhitePCar().move();new WhiteETCar().move();} } 復(fù)制代碼結(jié)果:
3.7.3 Good Code
正確的方式是: 定義一個(gè)抽象基類汽車Car。汽車Car分為兩種，一種是油車PCar，一種是電動車ETCar。
因?yàn)槌橄蠡惼嘋ar合成復(fù)用了IColor接口對象，所以子類油車PCar和電動車ETCar可以持有抽象基類Car的IColor接口對象。
因?yàn)镮Color對象一個(gè)接口，接口有多種顏色: 白色、黑色、黃色、綠色、棕等等。
如果每增加一種顏色，那么實(shí)現(xiàn)IColor接口即可，不需要像Bad Code通過繼承方式進(jìn)行類組合，不但解決了類爆炸的問題，而且解決了繼承帶來的高耦合弊端。因此，在類組合問題上，我們可以利用合成復(fù)用原則解決代碼冗余問題。
//--------------------------------------代碼塊一--------------------------------------- public interface IColor {String getName(); } //--------------------------------------代碼塊二--------------------------------------- public class RedColor implements IColor {@Overridepublic String getName() {return "Red";} } //--------------------------------------代碼塊三--------------------------------------- public class WhiteColor implements IColor {@Overridepublic String getName() {return "White";} } //--------------------------------------代碼塊四--------------------------------------- public abstract class Car {private IColor color;public abstract void move();public IColor getColor() {return color;}public Car setColor(IColor color) {this.color = color;return this;} } //--------------------------------------代碼塊五--------------------------------------- public class PCar extends Car {@Overridepublic void move() {System.out.println(getColor().getName() + " "+PCar.class.getSimpleName() +" is running!" );} } //--------------------------------------代碼塊六--------------------------------------- public class ETCar extends Car {@Overridepublic void move() {System.out.println(getColor().getName() + " "+PCar.class.getSimpleName() +" is running!" );} } //--------------------------------------代碼塊七--------------------------------------- public class Main {public static void main(String[] args) {PCar pCar = new PCar();ETCar etCar = new ETCar();RedColor redColor = new RedColor();WhiteColor whiteColor = new WhiteColor();pCar.setColor(redColor).move();pCar.setColor(whiteColor).move();etCar.setColor(redColor).move();etCar.setColor(whiteColor).move();} } 復(fù)制代碼結(jié)果:
3.7.4 思考復(fù)盤
組合和聚合到底有什么區(qū)別呢？
聚合關(guān)系的類里有另外一個(gè)類作為參數(shù)。BirdGroup類被gc之后，bird類的引用依然建在。這就是聚合。
public class BirdGroup{public Bird bird;public BirdGroup(Bird bird){this.bird = bird;} } 復(fù)制代碼組合關(guān)系的類里有另外一個(gè)類的實(shí)例化，如果Bird這個(gè)類被GC了，內(nèi)部的類的引用，隨之消失了，這就是組合。
public class Bird{public Wings wings;public Bird(){wings = new Wings () ;} } 復(fù)制代碼合成復(fù)用原則的優(yōu)點(diǎn)
使系統(tǒng)更加靈活，降低類與類之間的耦合度，一個(gè)類的變化對其他類造成的影響相對較小。
合成復(fù)用原則的缺點(diǎn)
破壞了包裝，同時(shí)包含的類的實(shí)現(xiàn)細(xì)節(jié)被隱藏。
好了，七大設(shè)計(jì)原則到現(xiàn)在已經(jīng)說完了，我們簡單的總結(jié)一下:
如果大家覺的上面表格比較復(fù)雜，那么用七句話總結(jié)就是:
單一職責(zé)原則告訴我們實(shí)現(xiàn)類要職責(zé)單一；
里氏替換原則告訴我們不要破壞繼承體系；
依賴倒置原則告訴我們要面向接口編程；
接口隔離原則告訴我們在設(shè)計(jì)接口的時(shí)候要精簡單一；
最小知識原則告訴我們要降低耦合；
合成復(fù)用原則告訴我們不要通過繼承方式實(shí)現(xiàn)功能和類組合；
而開閉原則是總綱，告訴我們要對擴(kuò)展開放，對修改關(guān)閉。
四、3大設(shè)計(jì)模式
說完七大設(shè)計(jì)原則，我們再說說3大設(shè)計(jì)模式，設(shè)計(jì)模式一般分為三種，第一種是創(chuàng)建型模式，第二種是結(jié)構(gòu)型模式，第三種是行為型模式。
當(dāng)我們關(guān)注類的對象，比如如何孵化出來類的對象?如何創(chuàng)建類的對象?如何new出來類的對象?如何維護(hù)類的對象關(guān)系?我們就需要使用到創(chuàng)建型模式。
當(dāng)我們關(guān)注類與類之間的關(guān)系，如 A 跟 B 類組合或生產(chǎn)關(guān)系的時(shí)候。我們就需要使用到結(jié)構(gòu)型模式。
當(dāng)我們關(guān)注類某一個(gè)方法功能的一個(gè)實(shí)現(xiàn)，我們就需要使用到行為型模式。
創(chuàng)建型模式、結(jié)構(gòu)型模式和行為型模式又分為23 種，由于篇幅有限，今天主要講解創(chuàng)建型模式的建造者設(shè)計(jì)模式，結(jié)構(gòu)型模式的適配器設(shè)計(jì)模式，行為型模式的策略設(shè)計(jì)模式和模板方法設(shè)計(jì)模式。剩余19種設(shè)計(jì)模式，小木箱將在后續(xù)文章進(jìn)行講解和梳理。
4.1 創(chuàng)建型模式
創(chuàng)建型模式本質(zhì)上是處理類的實(shí)例化，封裝了具體類的信息和隱藏了類的實(shí)例化過程。今天主要講解建造者設(shè)計(jì)模式
4.1.1 建造者設(shè)計(jì)模式
4.1.1.1 定義
建造者模式所完成的內(nèi)容就是通過將多個(gè)簡單對象通過一步步的組裝構(gòu)建出一個(gè)復(fù)雜對象的過程。
建造者設(shè)計(jì)模式滿足了單一職責(zé)原則以及可復(fù)用的技術(shù)、建造者獨(dú)立、易擴(kuò)展、便于控制細(xì)節(jié)風(fēng)險(xiǎn)。
但同時(shí)當(dāng)出現(xiàn)特別多的物料以及很多的組合后，類的不斷擴(kuò)展也會造成難以維護(hù)的問題。
建造者設(shè)計(jì)模式可以把重復(fù)的內(nèi)容抽象到數(shù)據(jù)庫中，按照需要配置。這樣就可以減少代碼中大量的重復(fù)。
4.1.1.2 B站視頻
《重學(xué)Java設(shè)計(jì)模式》第6章：建造者模式
4.1.1.3 Bad Code
這里我們模擬裝修公司對于設(shè)計(jì)出一些套餐裝修服務(wù)的場景。
很多裝修公司都會給出自家的套餐服務(wù)，一般有；歐式豪華、輕奢田園、現(xiàn)代簡約等等，而這些套餐的后面是不同的商品的組合。例如；一級&二級吊頂、多樂士涂料、圣象地板、馬可波羅地磚等等，按照不同的套餐的價(jià)格選取不同的品牌組合，最終再按照裝修面積給出一個(gè)整體的報(bào)價(jià)。
這里我們就模擬裝修公司想推出一些套餐裝修服務(wù)，按照不同的價(jià)格設(shè)定品牌選擇組合，以達(dá)到使用建造者模式的過程。
在模擬工程中提供了裝修中所需要的物料；ceilling(吊頂)、coat(涂料)、floor(地板)、tile(地磚)，這么四項(xiàng)內(nèi)容。（實(shí)際的裝修物料要比這個(gè)多的多）
4.1.1.3.1 代碼結(jié)構(gòu)
-
物料接口: Matter
- 物料接口提供了基本的信息，以保證所有的裝修材料都可以按照統(tǒng)一標(biāo)準(zhǔn)進(jìn)行獲取。
-
吊頂(ceiling)
- 一級頂: LevelOneCeiling
- 二級頂: LevelTwoCeiling
-
涂料(coat)
- 多樂士: DuluxCoat
- 立邦: LiBangCoat
-
地板(floor)
- 德爾
- 圣象
- 地磚(tile)
- 馬可波羅
以上就是本次裝修公司所提供的裝修配置單，接下我們會通過案例去使用不同的物料組合出不同的套餐服務(wù)。
public class DecorationPackageController {public String getMatterList(BigDecimal area, Integer level) {List<Matter> list = new ArrayList<Matter>(); // 裝修清單BigDecimal price = BigDecimal.ZERO; // 裝修價(jià)格// 豪華歐式if (1 == level) {LevelTwoCeiling levelTwoCeiling = new LevelTwoCeiling(); // 吊頂，二級頂DuluxCoat duluxCoat = new DuluxCoat(); // 涂料，多樂士ShengXiangFloor shengXiangFloor = new ShengXiangFloor(); // 地板，圣象list.add(levelTwoCeiling);list.add(duluxCoat);list.add(shengXiangFloor);price = price.add(area.multiply(new BigDecimal("0.2")).multiply(levelTwoCeiling.price()));price = price.add(area.multiply(new BigDecimal("1.4")).multiply(duluxCoat.price()));price = price.add(area.multiply(shengXiangFloor.price()));}// 輕奢田園if (2 == level) {LevelTwoCeiling levelTwoCeiling = new LevelTwoCeiling(); // 吊頂，二級頂LiBangCoat liBangCoat = new LiBangCoat(); // 涂料，立邦MarcoPoloTile marcoPoloTile = new MarcoPoloTile(); // 地磚，馬可波羅list.add(levelTwoCeiling);list.add(liBangCoat);list.add(marcoPoloTile);price = price.add(area.multiply(new BigDecimal("0.2")).multiply(levelTwoCeiling.price()));price = price.add(area.multiply(new BigDecimal("1.4")).multiply(liBangCoat.price()));price = price.add(area.multiply(marcoPoloTile.price()));}// 現(xiàn)代簡約if (3 == level) {LevelOneCeiling levelOneCeiling = new LevelOneCeiling(); // 吊頂，二級頂LiBangCoat liBangCoat = new LiBangCoat(); // 涂料，立邦DongPengTile dongPengTile = new DongPengTile(); // 地磚，東鵬list.add(levelOneCeiling);list.add(liBangCoat);list.add(dongPengTile);price = price.add(area.multiply(new BigDecimal("0.2")).multiply(levelOneCeiling.price()));price = price.add(area.multiply(new BigDecimal("1.4")).multiply(liBangCoat.price()));price = price.add(area.multiply(dongPengTile.price()));}StringBuilder detail = new StringBuilder("\r\n-------------------------------------------------------\r\n" +"裝修清單" + "\r\n" +"套餐等級：" + level + "\r\n" +"套餐價(jià)格：" + price.setScale(2, BigDecimal.ROUND_HALF_UP) + " 元\r\n" +"房屋面積：" + area.doubleValue() + " 平米\r\n" +"材料清單：\r\n");for (Matter matter: list) {detail.append(matter.scene()).append("：").append(matter.brand()).append("、").append(matter.model()).append("、平米價(jià)格：").append(matter.price()).append(" 元。\n");}return detail.toString();}} 復(fù)制代碼- 測試入口: Main
總結(jié):
4.1.1.3.2?輸出結(jié)果
------------------------------------------------------- 裝修清單 套餐等級：1 套餐價(jià)格：198064.39 元 房屋面積：132.52 平米 材料清單： 吊頂：裝修公司自帶、二級頂、平米價(jià)格：850 元。 涂料：多樂士(Dulux)、第二代、平米價(jià)格：719 元。 地板：圣象、一級、平米價(jià)格：318 元。------------------------------------------------------- 裝修清單 套餐等級：2 套餐價(jià)格：119865.00 元 房屋面積：98.25 平米 材料清單： 吊頂：裝修公司自帶、二級頂、平米價(jià)格：850 元。 涂料：立邦、默認(rèn)級別、平米價(jià)格：650 元。 地磚：馬可波羅(MARCO POLO)、缺省、平米價(jià)格：140 元。------------------------------------------------------- 裝修清單 套餐等級：3 套餐價(jià)格：90897.52 元 房屋面積：85.43 平米 材料清單： 吊頂：裝修公司自帶、一級頂、平米價(jià)格：260 元。 涂料：立邦、默認(rèn)級別、平米價(jià)格：650 元。 地磚：東鵬瓷磚、10001、平米價(jià)格：102 元。 復(fù)制代碼4.1.1.4 Good Code
工程結(jié)構(gòu)
├── Builder.java ├── DecorationPackageMenu.java ├── IMenu.java ├── Main.java ├── ceiling │?? ├── LevelOneCeiling.java │?? ├── LevelTwoCeiling.java │?? └── Matter.java ├── coat │?? ├── DuluxCoat.java │?? └── LiBangCoat.java ├── floor │?? ├── DerFloor.java │?? └── ShengXiangFloor.java └── tile ├── DongPengTile.java └── MarcoPoloTile.java 復(fù)制代碼建造者模型結(jié)構(gòu)
工程中有三個(gè)核心類和一個(gè)測試類，核心類是建造者模式的具體實(shí)現(xiàn)。與ifelse實(shí)現(xiàn)方式相比，多出來了兩個(gè)二外的類。具體功能如下；
- Builder，建造者類具體的各種組裝由此類實(shí)現(xiàn)。
- DecorationPackageMenu，是IMenu接口的實(shí)現(xiàn)類，主要是承載建造過程中的填充器。相當(dāng)于這是一套承載物料和創(chuàng)建者中間銜接的內(nèi)容。
好，那么接下來會分別講解幾個(gè)類的具體實(shí)現(xiàn)
定義裝修包接口
public interface IMenu {IMenu appendCeiling(Matter matter); // 吊頂IMenu appendCoat(Matter matter); // 涂料IMenu appendFloor(Matter matter); // 地板IMenu appendTile(Matter matter); // 地磚String getDetail(); // 明細(xì) } 復(fù)制代碼- 接口類中定義了填充各項(xiàng)物料的方法；吊頂、涂料、地板、地磚，以及最終提供獲取全部明細(xì)的方法。
裝修包實(shí)現(xiàn)
public class DecorationPackageMenu implements IMenu {private List<Matter> list = new ArrayList<Matter>(); // 裝修清單private BigDecimal price = BigDecimal.ZERO; // 裝修價(jià)格private BigDecimal area; // 面積private String grade; // 裝修等級；豪華歐式、輕奢田園、現(xiàn)代簡約private DecorationPackageMenu() {}public DecorationPackageMenu(Double area, String grade) {this.area = new BigDecimal(area);this.grade = grade;}public IMenu appendCeiling(Matter matter) {list.add(matter);price = price.add(area.multiply(new BigDecimal("0.2")).multiply(matter.price()));return this;}public IMenu appendCoat(Matter matter) {list.add(matter);price = price.add(area.multiply(new BigDecimal("1.4")).multiply(matter.price()));return this;}public IMenu appendFloor(Matter matter) {list.add(matter);price = price.add(area.multiply(matter.price()));return this;}public IMenu appendTile(Matter matter) {list.add(matter);price = price.add(area.multiply(matter.price()));return this;}public String getDetail() {StringBuilder detail = new StringBuilder("\r\n-------------------------------------------------------\r\n" +"裝修清單" + "\r\n" +"套餐等級：" + grade + "\r\n" +"套餐價(jià)格：" + price.setScale(2, BigDecimal.ROUND_HALF_UP) + " 元\r\n" +"房屋面積：" + area.doubleValue() + " 平米\r\n" +"材料清單：\r\n");for (Matter matter: list) {detail.append(matter.scene()).append("：").append(matter.brand()).append("、").append(matter.model()).append("、平米價(jià)格：").append(matter.price()).append(" 元。\n");}return detail.toString();}} 復(fù)制代碼- 裝修包的實(shí)現(xiàn)中每一個(gè)方法都會了?this，也就可以非常方便的用于連續(xù)填充各項(xiàng)物料。
- 同時(shí)在填充時(shí)也會根據(jù)物料計(jì)算平米數(shù)下的報(bào)價(jià)，吊頂和涂料按照平米數(shù)適量乘以常數(shù)計(jì)算。
- 最后同樣提供了統(tǒng)一的獲取裝修清單的明細(xì)方法。
建造者方法
public class Builder {public IMenu levelOne(Double area) {return new DecorationPackageMenu(area, "豪華歐式").appendCeiling(new LevelTwoCeiling()) // 吊頂，二級頂.appendCoat(new DuluxCoat()) // 涂料，多樂士.appendFloor(new ShengXiangFloor()); // 地板，圣象}public IMenu levelTwo(Double area){return new DecorationPackageMenu(area, "輕奢田園").appendCeiling(new LevelTwoCeiling()) // 吊頂，二級頂.appendCoat(new LiBangCoat()) // 涂料，立邦.appendTile(new MarcoPoloTile()); // 地磚，馬可波羅}public IMenu levelThree(Double area){return new DecorationPackageMenu(area, "現(xiàn)代簡約").appendCeiling(new LevelOneCeiling()) // 吊頂，二級頂.appendCoat(new LiBangCoat()) // 涂料，立邦.appendTile(new DongPengTile()); // 地磚，東鵬}} 復(fù)制代碼測試方法:
@Test public void test_Builder(){Builder builder = new Builder();// 豪華歐式System.out.println(builder.levelOne(132.52D).getDetail());// 輕奢田園System.out.println(builder.levelTwo(98.25D).getDetail());// 現(xiàn)代簡約System.out.println(builder.levelThree(85.43D).getDetail()); } 復(fù)制代碼結(jié)果:
------------------------------------------------------- 裝修清單 套餐等級：豪華歐式 套餐價(jià)格：198064.39 元 房屋面積：132.52 平米 材料清單： 吊頂：裝修公司自帶、二級頂、平米價(jià)格：850 元。 涂料：多樂士(Dulux)、第二代、平米價(jià)格：719 元。 地板：圣象、一級、平米價(jià)格：318 元。------------------------------------------------------- 裝修清單 套餐等級：輕奢田園 套餐價(jià)格：119865.00 元 房屋面積：98.25 平米 材料清單： 吊頂：裝修公司自帶、二級頂、平米價(jià)格：850 元。 涂料：立邦、默認(rèn)級別、平米價(jià)格：650 元。 地磚：馬可波羅(MARCO POLO)、缺省、平米價(jià)格：140 元。------------------------------------------------------- 裝修清單 套餐等級：現(xiàn)代簡約 套餐價(jià)格：90897.52 元 房屋面積：85.43 平米 材料清單： 吊頂：裝修公司自帶、一級頂、平米價(jià)格：260 元。 涂料：立邦、默認(rèn)級別、平米價(jià)格：650 元。 地磚：東鵬瓷磚、10001、平米價(jià)格：102 元 復(fù)制代碼- 測試結(jié)果是一樣的，調(diào)用方式也基本類似。但是目前的代碼結(jié)構(gòu)卻可以讓你很方便的很有調(diào)理的進(jìn)行擴(kuò)展業(yè)務(wù)開發(fā)。而不是像以往一樣把所有代碼都寫到ifelse里面。
4.1.1.5 Source Code
建造者不拘泥于形式，建造者模式用于創(chuàng)建一個(gè)復(fù)雜對象。在android中，Dialog就用到了建造者模式，第三方庫的okhttp、Retrofit等
public class Dialog {String title;boolean mCancelable = false;Dialog(String title,boolean mCanclable){this.title = title;this.mCancelable = mCanclable;}public void show() {System.out.print("show");}static class Builder{String title;boolean mCancelable = false;public Builder setCancelable(boolean flag) {mCancelable = flag;return this;}public Builder setTitle(String title) {this.title = title;return this;}public Dialog build(){return new Dialog(this.title,this.mCancelable);}} } 復(fù)制代碼4.1.1.6 注意事項(xiàng)
優(yōu)點(diǎn)：
客戶端不比知道產(chǎn)品內(nèi)部細(xì)節(jié)，將產(chǎn)品本身與產(chǎn)品創(chuàng)建過程解耦，使得相同的創(chuàng)建過程可以創(chuàng)建不同的產(chǎn)品對象可以更加精細(xì)地控制產(chǎn)品的創(chuàng)建過程，將復(fù)雜對象分門別類抽出不同的類別來，使得開發(fā)者可以更加方便地得到想要的產(chǎn)品
缺點(diǎn)：
產(chǎn)品屬性之間差異很大且屬性沒有默認(rèn)值可以指定，這種情況是沒法使用建造者模式的，我們可以試想，一個(gè)對象20個(gè)屬性，彼此之間毫無關(guān)聯(lián)且每個(gè)都需要手動指定，那么很顯然，即使使用了建造者模式也是毫無作用
4.2 結(jié)構(gòu)型模式
創(chuàng)建型模式本質(zhì)上是處理類或?qū)ο蟮慕M合，常見的結(jié)構(gòu)模型有類結(jié)構(gòu)型和對象結(jié)構(gòu)型。今天主要講解適配器設(shè)計(jì)模式
4.2.1 適配器設(shè)計(jì)模式
4.1.1.1 定義
適配器模式把一個(gè)類的接口變換成客戶端所期待的另一種接口，從而使原本因接口不匹配而無法在一起工作的兩個(gè)類能夠在一起工作，是作為兩個(gè)不兼容的接口之間的橋梁。
這種類型的設(shè)計(jì)模式屬于結(jié)構(gòu)型模式，它結(jié)合了兩個(gè)獨(dú)立接口的功能，適配器分為類適配器和對象適配器.
主要解決在軟件系統(tǒng)中，常常要將一些"現(xiàn)存的對象"放到新的環(huán)境中，而新環(huán)境要求的接口是現(xiàn)對象不能滿足的;
4.1.1.2 UML圖例
4.1.1.3 類適配器
類適配器是通過類的繼承來實(shí)現(xiàn)的。Adpater直接繼承了Target和Adaptee中的所有方法，并進(jìn)行改寫，從而實(shí)現(xiàn)了Target中的方法。
類適配器的缺點(diǎn)就是必須實(shí)現(xiàn)Target和Adaptee中的方法，由于Java不支持多繼承，所以通常將Target設(shè)計(jì)成接口，Adapter繼承自Adaptee然后實(shí)現(xiàn)Target接口。使用類適配器的方式來實(shí)現(xiàn)一下上邊的用雄蜂來冒充鴨子。
我們可以看到下面的案例雄蜂(Drone)具有蜂鳴聲(beep)、轉(zhuǎn)子旋轉(zhuǎn)(spin_rotors)和起飛(take_off)行為，鴨子Duck具有嘎嘎叫(quack)和飛(fly)行為
那么如何找到一個(gè)適配器讓雄蜂(Drone)的蜂鳴聲beep和鴨子(Duck)的嘎嘎叫(quack)適配呢
又如何找到一個(gè)適配器讓鴨子(鴨子)飛(fly)和雄蜂(Drone)的轉(zhuǎn)子旋轉(zhuǎn)(spin_rotors)、起飛(take_off)適配呢?
很顯然雄蜂適配器(DroneAdapter)嘎嘎叫(quack)可以適配雄蜂(Drone)蜂鳴聲(beep)
雄蜂適配器(DroneAdapter)嘎嘎叫(fly)也可以適配雄蜂(Drone)轉(zhuǎn)子旋轉(zhuǎn)(spin_rotors)和起飛(take_off)
//--------------------------------------代碼塊一--------------------------------------- public interface Drone {void beep();void spin_rotors();void take_off(); } //--------------------------------------代碼塊二--------------------------------------- public class SuperDrone implements Drone {public void beep() {System.out.println("Beep beep beep");}public void spin_rotors() {System.out.println("Rotors are spinning");}public void take_off() {System.out.println("Taking off");} } //--------------------------------------代碼塊三--------------------------------------- public interface Duck {public void quack();public void fly(); } //--------------------------------------代碼塊四--------------------------------------- public class DroneAdapter implements Duck {Drone drone;public DroneAdapter(Drone drone) {this.drone = drone;}public void quack() {drone.beep();}public void fly() {drone.spin_rotors();drone.take_off();} } //--------------------------------------代碼塊五--------------------------------------- public class DuckTestDrive {public static void main(String[] args) {Drone drone = new SuperDrone();Duck droneAdapter = new DroneAdapter(drone);droneAdapter.quack();droneAdapter.fly();} } 復(fù)制代碼結(jié)果:
4.1.1.4 對象適配器
對象適配器是使用組合的方法，在Adapter中會保留一個(gè)原對象（Adaptee）的引用，適配器的實(shí)現(xiàn)就是講Target中的方法委派給Adaptee對象來做，用Adaptee中的方法實(shí)現(xiàn)Target中的方法
對象適配器的好處就是，Adpater只需要實(shí)現(xiàn)Target中的方法就好啦。現(xiàn)在我們通過一個(gè)用火雞冒充鴨子的例子來看看如何使用適配器模式。
火雞(Turkey)具備火雞叫(gobble)和飛(fly)行為，鴨子(Duck)具備嘎嘎叫(quack)和飛(fly)的行為，找一個(gè)火雞適配器(TurkeyAdapter)讓鴨子(Duck)的嘎嘎叫(quack)適配火雞(Turkey)的火雞叫(gobble).讓鴨子(Duck)的飛(fly)適配火雞(Turkey)的飛(fly)，只要把火雞(Turkey)的對象傳給火雞適配器(TurkeyAdapter)即可.不改變野火雞(WildTurkey)火雞叫(gobble)和飛(fly)的行為.同時(shí)，不改變綠頭鴨(MallardDuck)的嘎嘎叫(quack) 和飛(fly)的行為.
//--------------------------------------代碼塊一--------------------------------------- public interface Duck {public void quack();public void fly(); } //--------------------------------------代碼塊二--------------------------------------- public interface Turkey {public void gobble();public void fly(); } //--------------------------------------代碼塊三--------------------------------------- public class TurkeyAdapter implements Duck {Turkey turkey;public TurkeyAdapter(Turkey turkey) {this.turkey = turkey;}public void quack() {turkey.gobble();}public void fly() {turkey.fly();} } //--------------------------------------代碼塊四--------------------------------------- public class WildTurkey implements Turkey {public void gobble() {System.out.println("Gobble gobble");}public void fly() {System.out.println("I'm flying a short distance");} } //--------------------------------------代碼塊五--------------------------------------- public class MallardDuck implements Duck {public void quack() {System.out.println("Quack");}public void fly() {System.out.println("I'm flying");} } //--------------------------------------代碼塊六--------------------------------------- public class DuckTestDrive {public static void main(String[] args) {Duck duck = new MallardDuck();Turkey turkey = new WildTurkey();Duck turkeyAdapter = new TurkeyAdapter(turkey);System.out.println("The Turkey says...");turkey.gobble();turkey.fly();System.out.println("\nThe Duck says...");testDuck(duck);System.out.println("\nThe TurkeyAdapter says...");testDuck(turkeyAdapter);}static void testDuck(Duck duck) {duck.quack();duck.fly();} } 復(fù)制代碼鴨子和火雞有相似之處，他們都會飛，雖然飛的不遠(yuǎn)，他們不太一樣的地方就是叫聲不太一樣，現(xiàn)在我們有一個(gè)火雞的類，有鴨子的抽象類也就是接口。
我們的適配器繼承自鴨子類并且保留了火雞的引用，重寫鴨子的飛和叫的方法，但是是委托給火雞的方法來實(shí)現(xiàn)的。在客戶端中，我們給適配器傳遞一個(gè)火雞的對象，就可以把它當(dāng)做鴨子來使用了。
結(jié)果:
4.1.1.5 Source Code
適配器模式可以用繼承實(shí)現(xiàn)，這里沒有更高的抽象，當(dāng)然也可以把Adapter的內(nèi)容抽象出去，僅僅演示，ListView、GridView適配了Adapter類。
//定義適配器類 public class Adapter {public void getView(int i){System.out.println("給出View"+i);} } //ListView 繼承了Adapter public class ListView extends Adapter{public void show(){System.out.print("循環(huán)顯示View");for(int i=0;i<3;i++){getView(i);}} } //GridView繼承了Adapter public class GridView extends Adapter{public void show(){...getView(i);} } 復(fù)制代碼在android中，ListView、RecyclerView都是用了適配器模式，ListView適配了Adapter，ListView只管ItemView，不管具體怎么展示，Adapter只管展示。就像讀卡器，讀卡器作為內(nèi)存和電腦之間的適配器。
4.1.1.6 注意事項(xiàng)
適配器模式的優(yōu)點(diǎn):
將目標(biāo)類和適配者類解耦，通過引入一個(gè)適配器類來重用現(xiàn)有的適配者類，而無須修改原有代碼。
增加了類的透明性和復(fù)用性，將具體的實(shí)現(xiàn)封裝在適配者類中，對于客戶端類來說是透明的，而且提高了適配者的復(fù)用性。
靈活性和擴(kuò)展性都非常好，通過使用配置文件，可以很方便地更換適配器，也可以在不修改原有代碼的基礎(chǔ)上增加新的適配器類，完全符合“開閉原則”。
適配器模式的缺點(diǎn):
過多地使用適配器，會讓系統(tǒng)非常零亂，不易整體進(jìn)行把握。比如，明明看到調(diào)用的是 A 接口，其實(shí)內(nèi)部被適配成了 B 接口的實(shí)現(xiàn)，一個(gè)系統(tǒng)如果太多出現(xiàn)這種情況，無異于一場災(zāi)難。因此如果不是很有必要，可以不使用適配器，而是直接對系統(tǒng)進(jìn)行重構(gòu)。
由于 JAVA 至多繼承一個(gè)類，所以至多只能適配一個(gè)適配者類，而且目標(biāo)類必須是抽象類。
一次最多只能適配一個(gè)適配者類，不能同時(shí)適配多個(gè)適配者。
目標(biāo)抽象類只能為接口，不能為類，其使用有一定的局限性;
適配器模式的使用時(shí)機(jī):
在實(shí)際的開發(fā)過程中，一個(gè)接口有大量的方法，但是對應(yīng)的不同類只需要關(guān)注部分方法，其他無關(guān)的方法全都實(shí)現(xiàn)過于繁瑣，尤其是涉及的實(shí)現(xiàn)類過多的情況。
想要建立一個(gè)可以重復(fù)使用的類，用于與一些彼此之間沒有太大關(guān)聯(lián)的一些類，包括一些可能在將來引進(jìn)的類一起工作。
如: 現(xiàn)有一個(gè)需要的目標(biāo)接口對象 Target，定義了大量相關(guān)的方法。但是在實(shí)際使用過程只需分別關(guān)注其中部分方法，而不是全部實(shí)現(xiàn)。在此場景中：被依賴的目標(biāo)對象TargetObj、適配器Adapter、客戶端Client等
// 目標(biāo)對象：定義了大量的相關(guān)方法 public interface TargetObj {void operation1();void operation2();void operation3();void operation4();void operation5(); }// 適配器：將目標(biāo)接口定義的方法全部做默認(rèn)實(shí)現(xiàn) public abstract class Adapter implements TargetObj {void operation1(){}void operation2(){}void operation3(){}void operation4(){}void operation5(){} }// 客戶端：采用匿名內(nèi)部類的方式實(shí)現(xiàn)需要的接口即可完成適配 public class Client {public static void main(String[] args) {Adapter adapter1 = new Adapter() {@Overridepublic void operation3() {// 僅僅實(shí)現(xiàn)需要關(guān)注的方法即可System.out.println("operation3")}}Adapter adapter2 = new Adapter() {@Overridepublic void operation5() {// 僅僅實(shí)現(xiàn)需要關(guān)注的方法即可System.out.println("operation5")}}adapter1.operation3();adapter2.operation5();}} 復(fù)制代碼4.3 行為型模式
4.3.1 策略設(shè)計(jì)模式
4.1.1.1 定義
策略模式定義是一系列封裝起來的一種算法，讓算法與算法之間可以相互替換。策略模式把算法委托于使用者，策略模式可以獨(dú)立變化。
比如我們要去某個(gè)地方，會根據(jù)距離的不同（或者是根據(jù)手頭經(jīng)濟(jì)狀況）來選擇不同的出行方式（共享單車、坐公交、滴滴打車等等），這些出行方式即不同的策略。
再比如活動促銷，打 9 折、打 3 折、打 7 折還是打 8 折？涉及具體的策略選擇時(shí)候，讓使用者選擇，使用者只關(guān)心對算法的封裝，我怎么樣去實(shí)現(xiàn)算法。使用者不需要管。下面我們就用策略設(shè)計(jì)模式實(shí)現(xiàn)一個(gè)圖書購買系統(tǒng).
4.1.2.2 Code Case
在一個(gè)圖書購買系統(tǒng)中，主要由一些幾種不同的折扣：
折扣一（NoDiscountStrategy）：對有些圖書沒有折扣。折扣算法對象返還0作為折扣值。
折扣二（FlatRateStrategy）：對有些圖書提供一個(gè)固定量值為1元的折扣。
折扣三（PercentageStrategy）：對有些圖書提供一個(gè)百分比的折扣，比如本書價(jià)格為 20元，折扣百分比為7%，那么折扣值就是20×7%=1.4（元)。
//--------------------------------------代碼塊一--------------------------------------- public class Book {private String name;private DiscountStrategy strategy;public Book(String name， DiscountStrategy strategy) {this.name = name;this.strategy = strategy;}public void setStrategy(DiscountStrategy strategy) {this.strategy = strategy;}public void getDiscount(){System.out.println("book name:"+ name + " ，the discount algorithm is: "+ strategy.getClass().getSimpleName()+"，the discounted price is: " + strategy.calcDiscount());} } //--------------------------------------代碼塊二--------------------------------------- public abstract class DiscountStrategy {private double price = 0;private int copies;public DiscountStrategy() {}public DiscountStrategy(double price， int copies) {this.price = price;this.copies = copies;}abstract double calcDiscount();public double getPrice() {return price;}public int getCopies() {return copies;} } //--------------------------------------代碼塊三--------------------------------------- public class FlatRateStrategy extends DiscountStrategy{private int discountPrice;public FlatRateStrategy(double price， int copies) {super(price，copies);}public void setDiscountPrice(int discountPrice) {this.discountPrice = discountPrice;}@Overridedouble calcDiscount() {return discountPrice * getCopies();} } //--------------------------------------代碼塊四--------------------------------------- public class NoDiscountStrategy extends DiscountStrategy{@Overridedouble calcDiscount() {return 0;} } //--------------------------------------代碼塊五--------------------------------------- public class PercentageStrategy extends DiscountStrategy{private double discountPercent;public PercentageStrategy(double price， int copies) {super(price， copies);}public void setDiscountPercent(double discountPercent) {this.discountPercent = discountPercent;}@Overridedouble calcDiscount() {return getCopies() * getPrice() * discountPercent;} } //--------------------------------------代碼塊六--------------------------------------- public class Client {public static void main(String[] args) {Book book1 = new Book("java design pattern"， new NoDiscountStrategy());book1.getDiscount();FlatRateStrategy rateStrategy = new FlatRateStrategy(23.0， 5);rateStrategy.setDiscountPrice(1);Book book2 = new Book("java design pattern"，rateStrategy);book2.getDiscount();System.out.println("Revise《java design pattern》discount algorithm\n：");PercentageStrategy percentageStrategy = new PercentageStrategy(23， 5);percentageStrategy.setDiscountPercent(0.07);book2.setStrategy(percentageStrategy);book2.getDiscount();} } 復(fù)制代碼結(jié)果:
4.1.2.3 Android Code
Android中RecyclerView的例子，我們給RecyclerView選擇布局方式的時(shí)候，就是選擇的策略模式
//假如RecyclerView 這樣寫 public class RecyclerView {private Layout layout;public void setLayout(Layout layout) {this.layout = layout;if(layout == "橫著"){}else if(layout == "豎著"){}else if(layout=="格子"){}else{} this.layout.doLayout();} } //這樣寫if就很多了 //排列的方式 public interface Layout {void doLayout(); } //豎著排列 public class LinearLayout implements Layout{@Overridepublic void doLayout() {System.out.println("LinearLayout");} } //網(wǎng)格排列 public class GridLayout implements Layout{@Overridepublic void doLayout() {System.out.println("GridLayout");} } public class RecyclerView {private Layout layout;public void setLayout(Layout layout) {this.layout = layout;this.layout.doLayout();} } 復(fù)制代碼當(dāng)然Android的源碼里面動畫時(shí)間插值器，用的也是策略設(shè)計(jì)模式，代碼就不貼了，大家可以結(jié)合源碼和Android設(shè)計(jì)模式之策略模式在項(xiàng)目中的實(shí)際使用總結(jié)文章中的UML圖進(jìn)行學(xué)習(xí).
4.1.2.4 注意事項(xiàng)
為什么要用策略設(shè)計(jì)模式?
比如我們有微信支付，有支付寶支付，還有銀聯(lián)支付和招商支付。如果邏輯都通過 if else 實(shí)現(xiàn)，那么 if-else 塊中的代碼量比較大時(shí)候，后續(xù)代碼的擴(kuò)展和維護(hù)就會逐漸變得非常困難且容易出錯，就算使用Switch也同樣違反了:
if (微信支付) {// 邏輯1 } else if (支付寶支付) {// 邏輯2 } else if (銀聯(lián)支付) {// 邏輯3 } else if(招商支付){// 邏輯4 }else{ // 邏輯5 } 復(fù)制代碼單一職責(zé)原則（一個(gè)類應(yīng)該只有一個(gè)發(fā)生變化的原因）：因?yàn)橹笮薷娜魏我粋€(gè)邏輯，當(dāng)前類都會被修改
開閉原則（對擴(kuò)展開放，對修改關(guān)閉）：如果此時(shí)需要添加（刪除）某個(gè)邏輯，那么不可避免的要修改原來的代碼
什么時(shí)候使用策略設(shè)計(jì)模式?
如果在一個(gè)系統(tǒng)里面有許多類，它們之間的區(qū)別僅在于它們的行為，那么使用策略模式可以動態(tài)地讓一個(gè)對象在許多行為中選擇一種行為。 一個(gè)系統(tǒng)需要動態(tài)地在幾種算法中選擇一種。
如果一個(gè)對象有很多的行為，如果不用恰當(dāng)?shù)哪Ｊ?#xff0c;這些行為就只好使用多重的條件選擇語句來實(shí)現(xiàn)。
不希望客戶端知道復(fù)雜的、與算法相關(guān)的數(shù)據(jù)結(jié)構(gòu)，在具體策略類中封裝算法和相關(guān)的數(shù)據(jù)結(jié)構(gòu)，提高算法的保密性與安全性。
策略模式的優(yōu)缺點(diǎn)是什么?
優(yōu)點(diǎn)：
- 策略模式提供了對“開閉原則”的完美支持，用戶可以在不修改原有系統(tǒng)的基礎(chǔ)上選擇算法或行為，也可以靈活地增加新的算法或行為。
- 策略模式提供了管理相關(guān)的算法族的辦法。
- 策略模式提供了可以替換繼承關(guān)系的辦法。
- 使用策略模式可以避免使用多重條件轉(zhuǎn)移語句。
缺點(diǎn)：
-
客戶端必須知道所有的策略類，并自行決定使用哪一個(gè)策略類。
-
策略模式將造成產(chǎn)生很多策略類，可以通過使用享元模式在一定程度上減少對象的數(shù)量。
4.3.2 模板方法設(shè)計(jì)模式
4.3.2.1 定義
模版模式是說對一個(gè)執(zhí)行過程進(jìn)行抽象分解，通過骨架和擴(kuò)展方法完成一個(gè)標(biāo)準(zhǔn)的主體邏輯和擴(kuò)展。我們很多時(shí)候，做監(jiān)控平臺也都是這樣的：對過程進(jìn)行標(biāo)準(zhǔn)化，對變化進(jìn)行定義，形成一個(gè)平臺邏輯和業(yè)務(wù)擴(kuò)展，完成一個(gè)產(chǎn)品模版。
4.3.2.2?UML?圖例
通過以下AbstractClass模板類我們可以看出來，PrivitiveOperation1()和PrivitiveOperation2()全部封裝在TemplateMethod()抽象方法里面，TemplateMethod()抽象方法父類控制執(zhí)行順序，子類負(fù)責(zé)實(shí)現(xiàn)即可。通過封裝不變部分，擴(kuò)展可變部分和提取公共部分代碼，便于維護(hù)和可拓展性。
提出問題
小木箱準(zhǔn)備煮茶和煮咖啡，煮茶的步驟有燒水、泡茶、加檸檬、倒水四個(gè)步驟，而煮咖啡的步驟有燒水、過濾咖啡、倒水、加牛奶四個(gè)步驟，請?jiān)诳刂婆_打印煮茶和煮咖啡的執(zhí)行流程。
分析問題
煮茶和煮咖啡的步驟中燒水和倒水動作是重復(fù)的，能不能抽取成模板方法呢?
解決問題
可以參考UML圖例、Good Code、Bad Code和模板方法設(shè)計(jì)模式源碼分析。
4.3.2.3 Bad Code
錯誤的編碼方式：將煮茶的步驟燒水→泡茶→倒水→加檸檬按順序執(zhí)行，煮咖啡的步驟燒水→過濾咖啡→倒水→加牛奶也按順序執(zhí)行，這樣的缺點(diǎn)是如果步驟很多，那么代碼顯得比較臃腫，代碼維護(hù)成本也會越來越高。
//--------------------------------------代碼塊一--------------------------------------- public class Tea {void prepareRecipe() {boilWater();steepTeaBag();pourInCup();addLemon();}public void boilWater() {System.out.println("Boiling water");}public void steepTeaBag() {System.out.println("Steeping the tea");}public void addLemon() {System.out.println("Adding Lemon");}public void pourInCup() {System.out.println("Pouring into cup");} } //--------------------------------------代碼塊二--------------------------------------- public class Coffee {void prepareRecipe() {boilWater();brewCoffeeGrinds();pourInCup();addSugarAndMilk();}public void boilWater() {System.out.println("Boiling water");}public void brewCoffeeGrinds() {System.out.println("Dripping Coffee through filter");}public void pourInCup() {System.out.println("Pouring into cup");}public void addSugarAndMilk() {System.out.println("Adding Sugar and Milk");} } //--------------------------------------代碼塊三--------------------------------------- public class Barista {public static void main(String[] args) {Tea tea = new Tea();Coffee coffee = new Coffee();System.out.println("Making tea...");tea.prepareRecipe();System.out.println("Making coffee...");coffee.prepareRecipe();} } 復(fù)制代碼結(jié)果:
4.3.2.4 Good Code
正確的編碼方式:首先將煮茶和煮咖啡共同動作燒水和倒水抽取成模板方法，并在父類執(zhí)行，然后煮茶的泡茶、加檸檬步驟，煮咖啡的過濾咖啡、加牛奶步驟分別差異化實(shí)現(xiàn)即可，最后要確保四個(gè)步驟執(zhí)行鏈準(zhǔn)確性。
//--------------------------------------代碼塊一--------------------------------------- public abstract class CaffeineBeverage {final void prepareRecipe() {boilWater();brew();pourInCup();addCondiments();}abstract void brew();abstract void addCondiments();void boilWater() {System.out.println("Boiling water");}void pourInCup() {System.out.println("Pouring into cup");} } //--------------------------------------代碼塊二--------------------------------------- public class Tea extends CaffeineBeverage {public void brew() {System.out.println("Steeping the tea");}public void addCondiments() {System.out.println("Adding Lemon");} } //--------------------------------------代碼塊三--------------------------------------- public class Coffee extends CaffeineBeverage {public void brew() {System.out.println("Dripping Coffee through filter");}public void addCondiments() {System.out.println("Adding Sugar and Milk");} } //--------------------------------------代碼塊四--------------------------------------- public class Barista {public static void main(String[] args) {Tea tea = new Tea();Coffee coffee = new Coffee();System.out.println("\nMaking tea...");tea.prepareRecipe();System.out.println("\nMaking coffee...");coffee.prepareRecipe();} 復(fù)制代碼結(jié)果:
4.3.2.5 Source Code
當(dāng)然Android的AsyncTask也能體現(xiàn)模板方法設(shè)計(jì)模式，我們可以看到execute方法內(nèi)部封裝了onPreExecute， doInBackground， onPostExecute這個(gè)算法框架。
用戶可以根據(jù)自己的需求來在覆寫這幾個(gè)方法，使得用戶可以很方便的使用異步任務(wù)來完成耗時(shí)操作，又可以通過onPostExecute來完成更新UI線程的工作。
//--------------------------------------代碼塊一---------------------------------------public final AsyncTask<Params， Progress， Result> execute(Params... params) {return executeOnExecutor(sDefaultExecutor， params);}public final AsyncTask<Params， Progress， Result> executeOnExecutor(Executor exec，Params... params) { //............................................................................mStatus = Status.RUNNING;// TODO: 關(guān)鍵模板方法onPreExecute();mWorker.mParams = params;exec.execute(mFuture);return this;}//--------------------------------------代碼塊二---------------------------------------public AsyncTask() {mWorker = new WorkerRunnable<Params， Result>() {public Result call() throws Exception {mTaskInvoked.set(true);Process.setThreadPriority(Process.THREAD_PRIORITY_BACKGROUND);// TODO: 關(guān)鍵執(zhí)行方法return postResult(doInBackground(mParams));}};} //--------------------------------------代碼塊三---------------------------------------private Result postResult(Result result) {Message message = sHandler.obtainMessage(MESSAGE_POST_RESULT，new AsyncTaskResult<Result>(this， result));message.sendToTarget();return result;} //--------------------------------------代碼塊四---------------------------------------private static class InternalHandler extends Handler {public void handleMessage(Message msg) {AsyncTaskResult result = (AsyncTaskResult) msg.obj;switch (msg.what) {case MESSAGE_POST_RESULT:result.mTask.finish(result.mData[0]);break;case MESSAGE_POST_PROGRESS:result.mTask.onProgressUpdate(result.mData);break;}}}//--------------------------------------代碼塊五---------------------------------------private void finish(Result result) {if (isCancelled()) {onCancelled(result);} else {// TODO: 關(guān)鍵模板方法onPostExecute(result);}mStatus = Status.FINISHED;} 復(fù)制代碼4.3.2.6 注意事項(xiàng)
當(dāng)然模板方法如果沒有梳理好方法與方法的調(diào)用鏈關(guān)系，那么模板方法會帶來代碼閱讀的難度，會讓人覺得難以理解。
五、總結(jié)與展望
《Android架構(gòu)演進(jìn) · 設(shè)計(jì)模式· 為什么建議你一定要學(xué)透設(shè)計(jì)模式》一文首先通過5W2H全方位的講解了設(shè)計(jì)模式對Android開發(fā)的價(jià)值，然后通過UML圖例、BadCode、Good Code、使用原則和思考復(fù)盤多維度分析了7大設(shè)計(jì)原則優(yōu)劣勢和核心思想，最后分別對創(chuàng)建型模式、行為型模式和結(jié)構(gòu)型模式的案例剖析了三大設(shè)計(jì)模式的實(shí)現(xiàn)細(xì)節(jié)。
因?yàn)槿绻δ芎唵?#xff0c;套用設(shè)計(jì)模式搭建，反而會增加了成本和系統(tǒng)的復(fù)雜度。因此，在工作中我們既不要生搬硬套設(shè)計(jì)模式，也不要過度去設(shè)計(jì)。我們要根據(jù)功能需求的復(fù)雜性設(shè)計(jì)系統(tǒng)。
在理解設(shè)計(jì)模式思想的基礎(chǔ)上，小木箱強(qiáng)烈建議大家結(jié)合框架源碼和項(xiàng)目源碼對每一個(gè)設(shè)計(jì)模式和設(shè)計(jì)原則，進(jìn)行深度理解和思考，最后才能針對合適的場景和問題正確的運(yùn)用。
當(dāng)然很多設(shè)計(jì)模式使用場景不是一種模式的唯一實(shí)現(xiàn)，可能是多種模式混合實(shí)現(xiàn)。因此，對Android同學(xué)發(fā)散思維和業(yè)務(wù)理解深度提出苛刻的要求。有的時(shí)候架構(gòu)能力是倒逼的，面對復(fù)雜的業(yè)務(wù)頻繁的變化，我們要勇于不斷的挑戰(zhàn)！
這也是小木箱強(qiáng)烈建議大家學(xué)透設(shè)計(jì)模式很重要的原因。希望通過這篇文章能夠讓你意識到學(xué)會設(shè)計(jì)模式的重要性。
下一章Android架構(gòu)演進(jìn) · 設(shè)計(jì)模式 · Android常見的4種創(chuàng)建型設(shè)計(jì)模式會從上而下帶大家揭秘常見創(chuàng)建型設(shè)計(jì)模式，我們下一篇見~
總結(jié)
以上是生活随笔為你收集整理的Android架构演进 · 设计模式· 为什么建议你一定要学透设计模式？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Excel中从身份证号提取出生日期
- 下一篇： Android3d结构光,为什么3D结构