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