很多Java開(kāi)發(fā)看到“樹(shù)形結(jié)構(gòu)”四個(gè)字第一反應(yīng)就是遞歸、遍歷、Stack。菜單權(quán)限、組織架構(gòu)、商品分類(lèi)、文件目錄幾乎每一個(gè)正經(jīng)的業(yè)務(wù)系統(tǒng)都逃不掉樹(shù)。但說(shuō)實(shí)話能把樹(shù)寫(xiě)明白的人真不多。我接手過(guò)不少老項(xiàng)目常見(jiàn)畫(huà)面是一個(gè)Service類(lèi)里塞了十幾個(gè)if每次拿到一個(gè)節(jié)點(diǎn)都要先判斷到底是不是葉子、有沒(méi)有子節(jié)點(diǎn)然后走完全不同的分支邏輯下一個(gè)人改代碼時(shí)頭皮都發(fā)麻。組合模式Composite Pattern就是沖著這個(gè)痛點(diǎn)來(lái)的。它是一種結(jié)構(gòu)型設(shè)計(jì)模式核心就一句話讓“單個(gè)對(duì)象”和“組合對(duì)象”在使用上保持一致讓客戶端可以像處理單個(gè)對(duì)象一樣處理一棵完整的樹(shù)。這篇文章我不會(huì)只念定義會(huì)把原理掰開(kāi)揉碎配合真實(shí)業(yè)務(wù)場(chǎng)景的Java實(shí)現(xiàn)把組合模式的應(yīng)用場(chǎng)景、結(jié)構(gòu)設(shè)計(jì)和落地經(jīng)驗(yàn)一次說(shuō)清楚。無(wú)論你是被權(quán)限樹(shù)折磨的后臺(tái)開(kāi)發(fā)還是準(zhǔn)備Java面試想答出差異化的人都值得看完。1. 組合模式到底在解決什么問(wèn)題1.1 樹(shù)形結(jié)構(gòu)處理的三個(gè)典型痛點(diǎn)先說(shuō)我實(shí)際見(jiàn)過(guò)的三個(gè)痛點(diǎn)。第一個(gè)類(lèi)型分裂。比如權(quán)限樹(shù)里有“部門(mén)節(jié)點(diǎn)”和“用戶節(jié)點(diǎn)”部門(mén)節(jié)點(diǎn)能掛子部門(mén)用戶節(jié)點(diǎn)不能。代碼寫(xiě)到最后到處都是if (node instanceof DeptNode)之類(lèi)的判斷。新增一種節(jié)點(diǎn)所有處理邏輯都要跟著改非常痛苦。真正可怕的是這種判斷不止出現(xiàn)在Service層還可能散布在Controller、工具類(lèi)、前端API組裝各處后期每加一個(gè)節(jié)點(diǎn)類(lèi)型都要全局搜索一遍所有引用點(diǎn)漏一個(gè)就出線上Bug。第二個(gè)遞歸業(yè)務(wù)代碼失控。統(tǒng)計(jì)部門(mén)人數(shù)、算商品總價(jià)、渲染菜單這類(lèi)需求通常就是一把梭寫(xiě)遞歸。寫(xiě)的時(shí)候挺爽后期需求一變遞歸方法越來(lái)越大參數(shù)越加越多基本沒(méi)法維護(hù)。我見(jiàn)過(guò)一個(gè)遞歸方法從最初統(tǒng)計(jì)部門(mén)人數(shù)慢慢擴(kuò)展成同時(shí)要統(tǒng)計(jì)工資、工齡、職級(jí)、編制數(shù)七個(gè)參數(shù)傳進(jìn)去內(nèi)部十幾個(gè)if測(cè)試根本沒(méi)法覆蓋全部分支。第三個(gè)客戶端調(diào)用不統(tǒng)一。有的接口返回單個(gè)對(duì)象有的返回列表有的直接把節(jié)點(diǎn)內(nèi)部字段暴露給外部導(dǎo)致調(diào)用方必須了解樹(shù)的所有內(nèi)部細(xì)節(jié)。比如菜單渲染邏輯明明調(diào)用方只需要知道“這個(gè)菜單底下有哪些菜單”卻要被迫了解菜單節(jié)點(diǎn)內(nèi)部是數(shù)組存儲(chǔ)還是列表存儲(chǔ)、子節(jié)點(diǎn)是延遲加載還是立即加載這種耦合到最后就是牽一發(fā)動(dòng)全身。這三個(gè)痛點(diǎn)的本質(zhì)其實(shí)是一個(gè)我們?nèi)鄙僖粋€(gè)統(tǒng)一的抽象把“葉子”和“容器”蒙在同一個(gè)接口后面。組合模式的價(jià)值正是在這一層。一旦抽象建立起來(lái)外部的所有邏輯都被統(tǒng)一成“對(duì)一棵樹(shù)的節(jié)點(diǎn)做操作”至于這個(gè)節(jié)點(diǎn)內(nèi)部是一整個(gè)部門(mén)還是一名單身員工根本不用關(guān)心。1.2 核心結(jié)構(gòu)Component、Leaf、Composite三個(gè)角色組合模式的結(jié)構(gòu)極其簡(jiǎn)單就三個(gè)角色。Component是抽象構(gòu)件定義了所有節(jié)點(diǎn)對(duì)外暴露的方法。它既包含業(yè)務(wù)上共同的操作比如獲取名稱(chēng)、計(jì)算價(jià)格、打印信息也定義了樹(shù)結(jié)構(gòu)相關(guān)的操作比如添加子節(jié)點(diǎn)、移除子節(jié)點(diǎn)、獲取子節(jié)點(diǎn)列表。在設(shè)計(jì)Component的時(shí)候有個(gè)容易忽略的點(diǎn)它不應(yīng)該只是一個(gè)數(shù)據(jù)裝配的載體更要承載業(yè)務(wù)行為。很多人把組合模式寫(xiě)成了純粹的樹(shù)狀數(shù)據(jù)結(jié)構(gòu)里里外外只有g(shù)etter和setter結(jié)果一棵樹(shù)建好了業(yè)務(wù)邏輯還是散落在各個(gè)Service里模式的核心價(jià)值就打了折扣。Leaf是葉子節(jié)點(diǎn)代表樹(shù)里沒(méi)有子分支的末端節(jié)點(diǎn)執(zhí)行真正的業(yè)務(wù)邏輯比如單個(gè)商品的定價(jià)、單個(gè)用戶的權(quán)限判斷。葉子節(jié)點(diǎn)內(nèi)部通常只有一條路自己算賬。所以它的add和remove要么不存在要么就只能拋異常。Composite是容器節(jié)點(diǎn)內(nèi)部持有一個(gè)List 負(fù)責(zé)管理子節(jié)點(diǎn)。它自己不真正干活而是遞歸地委托給子節(jié)點(diǎn)。這個(gè)“委托”是組合模式中最關(guān)鍵的機(jī)制Composite的方法實(shí)現(xiàn)里通常會(huì)遍歷children把同樣的方法調(diào)用轉(zhuǎn)發(fā)給每一個(gè)子節(jié)點(diǎn)再把結(jié)果匯總。換句大白話葉子是“實(shí)物”容器是“盒子”。盒子里可以放實(shí)物也可以再放盒子但無(wú)論盒子套幾層從外面看它們都能“打開(kāi)取東西、放東西、算總價(jià)值”。這就是組合模式想表達(dá)的“部分與整體的一致關(guān)系”。1.3 透明模式和安全模式到底選哪個(gè)寫(xiě)代碼時(shí)第一個(gè)分叉就是add、remove這些樹(shù)操作到底放不放到公共抽象里這一步的抉擇會(huì)影響后面所有的實(shí)現(xiàn)所以我單獨(dú)拎出來(lái)講。透明模式是放進(jìn)去。Leaf雖然用不到也必須實(shí)現(xiàn)然后拋出UnsupportedOperationException。好處是客戶端完全不用判斷類(lèi)型接口高度統(tǒng)一遍歷樹(shù)的時(shí)候不管碰到什么節(jié)點(diǎn)都能統(tǒng)一調(diào)用getChildren。安全模式是只放到Composite里Component里不定義樹(shù)操作方法。Leaf天然安全調(diào)用不存在的add方法在編譯期就會(huì)報(bào)錯(cuò)但客戶端如果要給節(jié)點(diǎn)加孩子必須先instanceof判斷接口的統(tǒng)一性稍微差一點(diǎn)。我個(gè)人的建議日常業(yè)務(wù)系統(tǒng)優(yōu)先選安全模式。原因很簡(jiǎn)單透明模式的“統(tǒng)一”在Java里很容易變成隱蔽的運(yùn)行期炸彈。葉子節(jié)點(diǎn)拋異常這個(gè)設(shè)計(jì)一旦遇到?jīng)]人處理的代碼路徑問(wèn)題定位成本遠(yuǎn)高于那幾次多余的instanceof判斷。而且真正使用樹(shù)的時(shí)候入口基本都是頂層容器需要“把葉子當(dāng)容器操作”的場(chǎng)景少之又少。你不需要為了一個(gè)幾乎不存在的場(chǎng)景犧牲類(lèi)型安全。當(dāng)然如果團(tuán)隊(duì)成員整體對(duì)設(shè)計(jì)模式理解比較深而且遍歷代碼確實(shí)存在“不管類(lèi)型統(tǒng)一操作子節(jié)點(diǎn)”的強(qiáng)需求透明模式也是一個(gè)可選的權(quán)衡。關(guān)鍵是把風(fēng)險(xiǎn)講清楚透明模式本質(zhì)上是把編譯期問(wèn)題推遲到運(yùn)行期這種“延遲暴雷”的成本往往在壓測(cè)和線上故障時(shí)才顯現(xiàn)。2. 哪些場(chǎng)景才是組合模式的最佳舞臺(tái)2.1 文件系統(tǒng)與目錄結(jié)構(gòu)文件系統(tǒng)就是組合模式教科書(shū)級(jí)別的例子。一個(gè)文件夾可以包含文件也可以包含子文件夾無(wú)論文件還是文件夾都支持重命名、查大小、刪除這些操作。如果用代碼模擬可以設(shè)計(jì)一個(gè)FileNode接口FileLeaf和DirectoryComposite分別實(shí)現(xiàn)它DirectoryComposite的getSize()方法遍歷所有孩子的getSize()并累加一個(gè)System.out.println就能打印整棵目錄樹(shù)的結(jié)構(gòu)。實(shí)際項(xiàng)目中這個(gè)模型比想象中更常用。我?guī)团笥雅挪檫^(guò)一個(gè)備份同步工具的問(wèn)題它要把本地某個(gè)大目錄的增量文件同步到云端目錄結(jié)構(gòu)十幾層深里面混著普通文件、隱藏文件、快捷方式、壓縮包。最開(kāi)始那套代碼用ArrayList 記錄所有路徑遍歷時(shí)搞不清目錄和文件的關(guān)系同步結(jié)果經(jīng)常錯(cuò)。后來(lái)?yè)Q成組合模式建模普通文件和目錄實(shí)現(xiàn)了統(tǒng)一的FileNode同步邏輯開(kāi)始變得非常清晰每個(gè)節(jié)點(diǎn)自己負(fù)責(zé)“是否需要同步”的判斷目錄再把判斷結(jié)果匯總給上層。2.2 組織架構(gòu)與部門(mén)統(tǒng)計(jì)企業(yè)OA里老總要求看全公司的部門(mén)樹(shù)計(jì)算每個(gè)部門(mén)包含所有子部門(mén)的人數(shù)、工資總額、座位數(shù)。部門(mén)下面掛員工部門(mén)下面還能掛子部門(mén)。不用組合模式你要寫(xiě)兩套統(tǒng)計(jì)方法一套遍歷部門(mén)一套遍歷員工最后再組合。部門(mén)一多、層級(jí)一變這套代碼就膨脹成災(zāi)難。用了組合模式之后Employee和Department都實(shí)現(xiàn)一個(gè)統(tǒng)一的OrgNode接口整棵組織樹(shù)就變成一堆OrgNode。統(tǒng)計(jì)工資時(shí)直接對(duì)根節(jié)點(diǎn)遞歸調(diào)用getTotalSalary每個(gè)Department的getTotalSalary內(nèi)部循環(huán)children把結(jié)果累加即可。以后加一個(gè)“實(shí)習(xí)生節(jié)點(diǎn)”、“外包人員節(jié)點(diǎn)”只要實(shí)現(xiàn)OrgNode接口統(tǒng)計(jì)邏輯一行都不用動(dòng)。這里有一個(gè)很典型的業(yè)務(wù)細(xì)節(jié)很多企業(yè)在算人頭的時(shí)候“是否算入部門(mén)人數(shù)”并不是簡(jiǎn)單的112往往還有兼任、掛職、借調(diào)這些規(guī)則。如果一開(kāi)始就把這些差異塞進(jìn)Department的統(tǒng)計(jì)方法里后期必然失控。組合模式的正確打開(kāi)方式是把“一個(gè)人怎么統(tǒng)計(jì)”的規(guī)則下沉到葉子節(jié)點(diǎn)內(nèi)部讓每個(gè)人自己回答“我該算進(jìn)多少人頭”容器只管累加。這個(gè)設(shè)計(jì)思路能讓你避免大量“特例判斷”。2.3 菜單、分類(lèi)與權(quán)限樹(shù)后臺(tái)管理系統(tǒng)的菜單渲染、商品多級(jí)分類(lèi)、角色權(quán)限樹(shù)是Java開(kāi)發(fā)碰到樹(shù)最多的三個(gè)地方。這些場(chǎng)景有個(gè)共同點(diǎn)節(jié)點(diǎn)除了結(jié)構(gòu)關(guān)系還帶著很多業(yè)務(wù)狀態(tài)比如菜單是否隱藏、分類(lèi)是否啟用、權(quán)限節(jié)點(diǎn)的半選狀態(tài)。用組合模式建模時(shí)通常會(huì)將通用方法定義在抽象類(lèi)里比如getName、getVisible、checkPermission。葉子節(jié)點(diǎn)自己判斷權(quán)限碼容器節(jié)點(diǎn)把判斷結(jié)果匯聚給父級(jí)。我最常用到的一個(gè)套路是節(jié)點(diǎn)的checkPermission()方法先檢查自己再遞歸子節(jié)點(diǎn)只要有一個(gè)節(jié)點(diǎn)有權(quán)限就返回true。這和權(quán)限樹(shù)“父節(jié)點(diǎn)有權(quán)限子節(jié)點(diǎn)沒(méi)權(quán)限”的逆向判斷完全合拍。權(quán)限樹(shù)還有一個(gè)細(xì)節(jié)值得多說(shuō)前端渲染時(shí)經(jīng)常需要“半選”狀態(tài)就是父節(jié)點(diǎn)只有部分子節(jié)點(diǎn)被選中。這種情況下父節(jié)點(diǎn)不能簡(jiǎn)單返回true或false它需要同時(shí)統(tǒng)計(jì)“選中子節(jié)點(diǎn)數(shù)”和“總子節(jié)點(diǎn)數(shù)”然后用1/0/2三種狀態(tài)標(biāo)記。這種多態(tài)化判斷如果散落在外層寫(xiě)起來(lái)費(fèi)勁放在Composite內(nèi)部反而很自然——因?yàn)榘脒x本來(lái)就是容器節(jié)點(diǎn)特有的問(wèn)題葉子節(jié)點(diǎn)只會(huì)是選中或未選中。2.4 規(guī)則引擎與XML/JSON樹(shù)解析很多Java開(kāi)發(fā)者不知道規(guī)則引擎里到處都是組合模式。一個(gè)優(yōu)惠規(guī)則可以是“滿199減100”這種葉子規(guī)則也可以是“滿199減100且僅限生鮮品類(lèi)”這種組合規(guī)則。執(zhí)行的時(shí)候葉子規(guī)則自己判斷組合規(guī)則把子規(guī)則的結(jié)果用AND/OR合并。這類(lèi)結(jié)構(gòu)用組合模式建模后新增規(guī)則類(lèi)型只需要新增一個(gè)類(lèi)不需要修改執(zhí)行器。我記得之前在訂單中心重構(gòu)優(yōu)惠券系統(tǒng)舊代碼里規(guī)則全部寫(xiě)在一個(gè)超級(jí)大的RuleExecutor里面十幾個(gè)boolean方法互相調(diào)用改一個(gè)規(guī)則就擔(dān)心影響其他優(yōu)惠的疊加效果。重構(gòu)之后每個(gè)規(guī)則節(jié)點(diǎn)自己判斷組合節(jié)點(diǎn)用AND/OR聚合優(yōu)惠疊加邏輯瞬間變得透明。測(cè)試也好寫(xiě)了可以直接構(gòu)造一棵規(guī)則樹(shù)指定結(jié)果驗(yàn)證聚合邏輯是否符合預(yù)期。再比如XML的DOM模型Element可以包含子Element也可以包含Text文本節(jié)點(diǎn)所有節(jié)點(diǎn)都實(shí)現(xiàn)Node接口——這本身就是組合模式的經(jīng)典實(shí)現(xiàn)。只要解析過(guò)XML的人其實(shí)早就接觸過(guò)組合模式只是沒(méi)意識(shí)到而已。JSON樹(shù)遍歷工具、表單動(dòng)態(tài)渲染引擎、審批流程的會(huì)簽/或簽節(jié)點(diǎn)設(shè)計(jì)本質(zhì)上也都是同一套思路。3. 實(shí)戰(zhàn)用組合模式實(shí)現(xiàn)商品套餐計(jì)算3.1 場(chǎng)景設(shè)定與接口設(shè)計(jì)我挑一個(gè)貼近電商業(yè)務(wù)的例子商品套餐。需求是這樣的商品可以是單品也可以是一個(gè)套餐。套餐里可以包含若干個(gè)單品也可以包含別的套餐。無(wú)論什么東西我都想知道總價(jià)、總件數(shù)、名稱(chēng)列表。第一步定義抽象節(jié)點(diǎn)。采用組合模式的標(biāo)準(zhǔn)骨架。我這里先給出透明模式的寫(xiě)法方便在一個(gè)類(lèi)里演示完整結(jié)構(gòu)后面再講生產(chǎn)環(huán)境怎么改成安全模式public abstract class ProductNode { protected String name; public ProductNode(String name) { this.name name; } public abstract double getPrice(); public abstract int getCount(); public void add(ProductNode child) { throw new UnsupportedOperationException(當(dāng)前節(jié)點(diǎn)不支持添加子節(jié)點(diǎn)); } public ListProductNode getChildren() { throw new UnsupportedOperationException(當(dāng)前節(jié)點(diǎn)不是容器節(jié)點(diǎn)); } }這里把name設(shè)計(jì)成protected是為了讓子類(lèi)直接使用getPrice和getCount做成抽象方法強(qiáng)制每個(gè)節(jié)點(diǎn)實(shí)現(xiàn)自己的計(jì)算邏輯。add和getChildren默認(rèn)不支持這樣葉子節(jié)點(diǎn)可以不實(shí)現(xiàn)它們。3.2 實(shí)現(xiàn)葉子節(jié)點(diǎn)和容器節(jié)點(diǎn)葉子節(jié)點(diǎn)就是單品價(jià)格是寫(xiě)死的數(shù)量是1public class ProductItem extends ProductNode { private double price; public ProductItem(String name, double price) { super(name); this.price price; } Override public double getPrice() { return price; } Override public int getCount() { return 1; } }容器節(jié)點(diǎn)是套餐內(nèi)部維護(hù)一個(gè)子節(jié)點(diǎn)列表getPrice和getCount都是遞歸匯總public class ProductPackage extends ProductNode { private ListProductNode children new ArrayList(); public ProductPackage(String name) { super(name); } Override public void add(ProductNode child) { children.add(child); } Override public ListProductNode getChildren() { return children; } Override public double getPrice() { double total 0; for (ProductNode child : children) { total child.getPrice(); } return total; } Override public int getCount() { int count 0; for (ProductNode child : children) { count child.getCount(); } return count; } }注意兩個(gè)類(lèi)的getPrice和getCount在調(diào)用方式上完全一致客戶端根本不需要判斷列表里的對(duì)象到底是ProductItem還是ProductPackage。這種“假裝自己是同一種東西”的能力就是組合模式的核心魔法。3.3 客戶端調(diào)用與結(jié)果驗(yàn)證模擬一個(gè)七夕禮盒套餐ProductPackage root new ProductPackage(七夕禮盒套裝); ProductPackage snacks new ProductPackage(零食大禮包); snacks.add(new ProductItem(巧克力, 99)); snacks.add(new ProductItem(曲奇餅干, 45)); root.add(snacks); root.add(new ProductItem(鮮花, 128)); System.out.println(總價(jià) root.getPrice()); System.out.println(總件數(shù) root.getCount());輸出結(jié)果總價(jià)272.0總件數(shù)3。完全符合預(yù)期。這里最妙的地方在于root本身也是一個(gè)ProductPackage它可以再被塞進(jìn)另一個(gè)更大的禮盒。只要你愿意可以無(wú)限嵌套而每一層的調(diào)用代碼長(zhǎng)得一模一樣。以后要增加“優(yōu)惠券節(jié)點(diǎn)”只需要新增一個(gè)ProductCoupon實(shí)現(xiàn)ProductNode改一行都不用改客戶端代碼。3.4 樹(shù)結(jié)構(gòu)和遞歸遍歷的工程實(shí)現(xiàn)業(yè)務(wù)系統(tǒng)里經(jīng)常要把這棵樹(shù)打印出來(lái)或者轉(zhuǎn)成前端需要的JSON結(jié)構(gòu)。加一個(gè)遞歸遍歷方法public void traverse(ProductNode node, String prefix) { System.out.println(prefix node.name); for (ProductNode child : node.getChildren()) { traverse(child, prefix ); } }調(diào)用后輸出的結(jié)構(gòu)長(zhǎng)這樣七夕禮盒套裝 零食大禮包 巧克力 曲奇餅干 鮮花對(duì)于只有價(jià)格和數(shù)量的場(chǎng)景這段代碼已經(jīng)很好用了。但生產(chǎn)環(huán)境往往還要應(yīng)對(duì)更復(fù)雜的遍歷需求我會(huì)加一個(gè)函數(shù)式接口增強(qiáng)它把“遍歷邏輯”和“業(yè)務(wù)處理”徹底分離public void traverse(ProductNode node, ConsumerProductNode action) { action.accept(node); for (ProductNode child : node.getChildren()) { traverse(child, action); } }調(diào)用的時(shí)候傳入任意處理邏輯比如篩選有效期內(nèi)的商品、計(jì)算平均價(jià)格、收集所有葉子節(jié)點(diǎn)名。這樣后續(xù)增加新的遍歷玩法時(shí)不需要改動(dòng)ProductNode這棵樹(shù)的代碼只新增一個(gè)Consumer實(shí)現(xiàn)即可。這種模式和Java 8之后的Stream思想非常契合代碼看起來(lái)也清爽得多。3.5 生產(chǎn)環(huán)境的增強(qiáng)安全模式、線程安全與泛型把上面的demo搬到生產(chǎn)環(huán)境前我會(huì)做三件事。第一改安全模式。把a(bǔ)dd、getChildren從ProductNode挪到ProductPackage或者單獨(dú)拆一個(gè)Composite接口出來(lái)避免葉子節(jié)點(diǎn)拋異常的可能。這個(gè)改動(dòng)的邊際成本很低但能減少一類(lèi)隱蔽的運(yùn)行時(shí)錯(cuò)誤。你總不希望線上日志里出現(xiàn)“UnsupportedOperationException”之后再回頭改接口設(shè)計(jì)吧。第二處理并發(fā)。如果樹(shù)結(jié)構(gòu)會(huì)被多線程并發(fā)修改普通的ArrayList會(huì)出大問(wèn)題。讀多寫(xiě)少時(shí)children可以用CopyOnWriteArrayList寫(xiě)頻繁時(shí)遍歷前先對(duì)children做一個(gè)快照防止迭代過(guò)程中出現(xiàn)ConcurrentModificationException。樹(shù)結(jié)構(gòu)并發(fā)修改是最容易出隱蔽Bug的地方之一而且復(fù)現(xiàn)困難壓測(cè)一跑幾百個(gè)線程同時(shí)加節(jié)點(diǎn)問(wèn)題立刻爆發(fā)。第三加泛型。如果節(jié)點(diǎn)本身就是業(yè)務(wù)對(duì)象可以定義Node 讓T承載具體的業(yè)務(wù)數(shù)據(jù)這樣組合模式就和業(yè)務(wù)模型解耦了。我用過(guò)一個(gè)方案抽象節(jié)點(diǎn)只維護(hù)結(jié)構(gòu)具體業(yè)務(wù)數(shù)據(jù)放在泛型T里這樣一套樹(shù)結(jié)構(gòu)工具可以復(fù)用到菜單、分類(lèi)、權(quán)限多個(gè)模塊代碼復(fù)用率很高。這三步做完才是能在線上扛得住業(yè)務(wù)的組合模式而不是上課用的玩具demo。4. 那些年踩過(guò)的坑組合模式避坑指南4.1 無(wú)限遞歸與棧溢出組合模式最大的安全風(fēng)險(xiǎn)就是循環(huán)引用。如果A節(jié)點(diǎn)添加的時(shí)候把B掛上去B又把自己的父節(jié)點(diǎn)A加回來(lái)遞歸調(diào)用瞬間進(jìn)入死循環(huán)直到StackOverflowError。這個(gè)問(wèn)題在業(yè)務(wù)系統(tǒng)里出現(xiàn)的頻率比你想象的高得多——尤其是從數(shù)據(jù)庫(kù)加載樹(shù)結(jié)構(gòu)時(shí)數(shù)據(jù)臟了父ID指回來(lái)整個(gè)接口直接崩。我的習(xí)慣是在add方法里做兩個(gè)檢查一是禁止添加this本身二是遞歸檢查父節(jié)點(diǎn)鏈禁止把祖先節(jié)點(diǎn)加進(jìn)來(lái)。實(shí)現(xiàn)大約這樣public void add(ProductNode child) { if (child this) { throw new IllegalArgumentException(不能把自身作為子節(jié)點(diǎn)); } ProductNode current this; while (current ! null) { if (current child) { throw new IllegalArgumentException(不能把祖先節(jié)點(diǎn)作為子節(jié)點(diǎn)); } current current.parent; } children.add(child); }這里引入了parent字段順手解決了兩個(gè)問(wèn)題找根節(jié)點(diǎn)和環(huán)檢測(cè)。不過(guò)要注意parent字段的維護(hù)需要在add和remove兩個(gè)方法里都做漏了就會(huì)產(chǎn)生“幽靈父節(jié)點(diǎn)”遍歷時(shí)倒是不影響但一旦用到parent屬性就全亂套了。4.2 刪除與內(nèi)存釋放remove方法有幾個(gè)細(xì)節(jié)容易被忽略。刪除一個(gè)容器節(jié)點(diǎn)時(shí)它下面的所有子孫節(jié)點(diǎn)如果還被其他業(yè)務(wù)對(duì)象引用著比如緩存會(huì)一直駐留內(nèi)存。我踩過(guò)一次坑一個(gè)權(quán)限樹(shù)每次刪除父節(jié)點(diǎn)子節(jié)點(diǎn)還留在本地緩存里結(jié)果用戶權(quán)限明明被刪了前端卻還能看到舊菜單。后來(lái)排查才知道是緩存沒(méi)清而緩存的key只存了子節(jié)點(diǎn)沒(méi)有關(guān)聯(lián)父節(jié)點(diǎn)。正確做法是刪除時(shí)清掉該節(jié)點(diǎn)的children列表或者配合WeakReference做緩存。同時(shí)刪除時(shí)要維護(hù)好parent引用否則getsParent和環(huán)檢測(cè)都會(huì)出問(wèn)題。另外一個(gè)實(shí)踐細(xì)節(jié)如果樹(shù)很大刪除操作頻繁建議先刪除葉子、再向上刪除容器避免刪除過(guò)程中樹(shù)被破壞。4.3 遞歸性能深度很深怎么辦遞歸是組合模式最自然的使用方式但它也有物理極限。JVM默認(rèn)棧深大約幾百到幾千層業(yè)務(wù)里樹(shù)超過(guò)1000層雖然少見(jiàn)但確有發(fā)生比如深度分類(lèi)樹(shù)、論壇蓋樓、超長(zhǎng)審批鏈。真遇到這種情況可以用顯式棧迭代替代遞歸public static void traverseIterative(ProductNode root) { DequeProductNode stack new ArrayDeque(); stack.push(root); while (!stack.isEmpty()) { ProductNode node stack.pop(); System.out.println(node.name); for (ProductNode child : node.getChildren()) { stack.push(child); } } }順序會(huì)從深度優(yōu)先變成逆序但結(jié)構(gòu)本身沒(méi)問(wèn)題遍歷方法調(diào)整一下即可。很多人在面試時(shí)不會(huì)主動(dòng)聊這個(gè)細(xì)節(jié)但一旦說(shuō)出來(lái)面試官會(huì)眼前一亮。除了遍歷還要注意遞歸方法里的臨時(shí)對(duì)象生命周期盡量用局部變量避免遞歸期間撐爆堆內(nèi)存。4.4 組合模式 vs 裝飾器模式別搞混組合模式和裝飾器模式都圍繞樹(shù)形結(jié)構(gòu)剛學(xué)的時(shí)候很容易混。簡(jiǎn)單區(qū)分組合模式解決“部分-整體”的層次問(wèn)題葉子可以組成容器容器可以再套容器客戶端統(tǒng)一調(diào)用。裝飾器模式解決“動(dòng)態(tài)增強(qiáng)”問(wèn)題把一個(gè)對(duì)象包在一個(gè)新對(duì)象里新對(duì)象在原有行為上增加職責(zé)包裝層數(shù)不強(qiáng)調(diào)“樹(shù)形組織”而是層層套殼。最直觀的記憶方式組合模式是橫向長(zhǎng)樹(shù)枝裝飾器是縱向套套娃。實(shí)際項(xiàng)目里兩個(gè)模式經(jīng)常合作先組合出樹(shù)再用裝飾器給節(jié)點(diǎn)加緩存、加日志、加權(quán)限校驗(yàn)。如果你在面試時(shí)能把這兩個(gè)模式的關(guān)系講清楚印象分會(huì)直接拉高——因?yàn)榇蠖鄶?shù)人只背定義沒(méi)人講清楚它們?nèi)绾未钆涫褂谩?.5 高頻問(wèn)題速查表整理了一張我在實(shí)戰(zhàn)中經(jīng)常用到的問(wèn)題速查表方便排查時(shí)對(duì)照問(wèn)題現(xiàn)象根因分析處理方案遞歸調(diào)用棧溢出樹(shù)存在循環(huán)引用add時(shí)檢查this與祖先鏈刪除節(jié)點(diǎn)后子節(jié)點(diǎn)仍可訪問(wèn)刪除未清空children刪除容器節(jié)點(diǎn)時(shí)遞歸清空葉子節(jié)點(diǎn)調(diào)用add拋異常透明模式的通病優(yōu)先改安全模式多線程遍歷樹(shù)數(shù)據(jù)錯(cuò)亂ArrayList并發(fā)修改CopyOnWriteArrayList或快照深度超1000層遞歸卡頓JVM默認(rèn)棧深限制顯式棧迭代遍歷新增節(jié)點(diǎn)類(lèi)型改動(dòng)大缺少統(tǒng)一Component抽象從業(yè)務(wù)類(lèi)型中抽取公共接口這個(gè)表也可以當(dāng)成面試復(fù)盤(pán)清單每個(gè)問(wèn)題都要能展開(kāi)講三五分鐘基本就沒(méi)問(wèn)題了。4.6 面試官想聽(tīng)什么一套可以照抄的回答思路組合模式在Java面試?yán)锍霈F(xiàn)頻率很高但大部分人只能說(shuō)出定義沒(méi)有“項(xiàng)目味”。我的建議是按這五步答第一步描述場(chǎng)景點(diǎn)出痛點(diǎn)。比如“我在處理權(quán)限樹(shù)的時(shí)候節(jié)點(diǎn)分部門(mén)、用戶、角色三種統(tǒng)計(jì)規(guī)則又不一樣代碼里全是類(lèi)型判斷每次加類(lèi)型都改一遍”。第二步講組合模式怎么破局。把三種節(jié)點(diǎn)抽象成統(tǒng)一的PermissionNode部門(mén)和角色容器再持子節(jié)點(diǎn)列表統(tǒng)一遞歸處理。第三步給一個(gè)小例子能說(shuō)代碼就不要只講概念。比如商品套餐算總價(jià)隨手畫(huà)一下三個(gè)角色的關(guān)系。你不需要背完整代碼關(guān)鍵是講清楚Component是抽象、Leaf是葉子、Composite持有List遞歸匯總。第四步主動(dòng)講缺點(diǎn)。透明模式的安全隱患、深遞歸的棧溢出風(fēng)險(xiǎn)、循環(huán)引用要預(yù)防說(shuō)完這些面試官基本就知道你踩過(guò)坑。只講優(yōu)點(diǎn)的候選人大概率是背書(shū)的。第五步如果時(shí)間允許補(bǔ)一句組合模式和裝飾器模式的區(qū)別展現(xiàn)橫向?qū)Ρ饶芰?。我一般?huì)說(shuō)“兩個(gè)模式都會(huì)遞歸套用對(duì)象但組合模式解決的是部分和整體的關(guān)系裝飾器解決的是職責(zé)疊加”這樣就把層次感帶出來(lái)了。最后再補(bǔ)一個(gè)實(shí)操細(xì)節(jié)如果你要處理的是數(shù)據(jù)庫(kù)里已經(jīng)存在的樹(shù)形數(shù)據(jù)比如一張菜單表parentId結(jié)構(gòu)組合模式依然適用——先從數(shù)據(jù)庫(kù)一次性查出來(lái)在內(nèi)存里組裝成樹(shù)再遞歸處理。組裝階段要注意防止數(shù)據(jù)臟導(dǎo)致的環(huán)引用這也是我前面強(qiáng)調(diào)add方法做環(huán)檢測(cè)的原因。我個(gè)人在實(shí)際項(xiàng)目里用得最多的其實(shí)是給抽象節(jié)點(diǎn)加parent引用這個(gè)細(xì)節(jié)它讓權(quán)限樹(shù)里的“節(jié)點(diǎn)移動(dòng)”“權(quán)限繼承”需求都變得非常簡(jiǎn)單。組合模式不炫技它真正的價(jià)值是讓一棵樹(shù)的結(jié)構(gòu)更健康讓后續(xù)加需求、改需求的時(shí)候不心驚膽戰(zhàn)。希望這篇文章能把組合模式講透下次你遇到樹(shù)形結(jié)構(gòu)時(shí)第一反應(yīng)不再是堆遞歸而是想想這里是不是該抽出Component了。