轉(zhuǎn)載自?樹形結(jié)構(gòu)的處理——組合模式（四）

1 透明組合模式與安全組合模式

????? 通過引入組合模式，Sunny公司設(shè)計的殺毒軟件具有良好的可擴(kuò)展性，在增加新的文件類型時，無須修改現(xiàn)有類庫代碼，只需增加一個新的文件類作為AbstractFile類的子類即可，但是由于在AbstractFile中聲明了大量用于管理和訪問成員構(gòu)件的方法，例如add()、remove()等方法，我們不得不在新增的文件類中實現(xiàn)這些方法，提供對應(yīng)的錯誤提示和異常處理。為了簡化代碼，我們有以下兩個解決方案：

??????解決方案一：將葉子構(gòu)件的add()、remove()等方法的實現(xiàn)代碼移至AbstractFile類中，由AbstractFile提供統(tǒng)一的默認(rèn)實現(xiàn)，代碼如下所示：

[java]?view plain?copy

//提供默認(rèn)實現(xiàn)的抽象構(gòu)件類??

abstract?class?AbstractFile?{??

????public?void?add(AbstractFile?file)?{??

????????System.out.println("對不起，不支持該方法！");??

????}??

??????

????public?void?remove(AbstractFile?file)?{??

????????System.out.println("對不起，不支持該方法！");??

????}??

??????

????public?AbstractFile?getChild(int?i)?{??

????????System.out.println("對不起，不支持該方法！");??

????????return?null;??

????}??

??????

????public?abstract?void?killVirus();??

}??

????? 如果客戶端代碼針對抽象類AbstractFile編程，在調(diào)用文件對象的這些方法時將出現(xiàn)錯誤提示。如果不希望出現(xiàn)任何錯誤提示，我們可以在客戶端定義文件對象時不使用抽象層，而直接使用具體葉子構(gòu)件本身，客戶端代碼片段如下所示：

[java]?view plain?copy

class?Client?{??

????public?static?void?main(String?args[])?{??

????????//不能透明處理葉子構(gòu)件??

????????ImageFile?file1,file2;??

????????TextFile?file3,file4;??

????????VideoFile?file5;??

????????AbstractFile?folder1,folder2,folder3,folder4;??

????????//其他代碼省略??

??????}??

}??

????? 這樣就產(chǎn)生了一種不透明的使用方式，即在客戶端不能全部針對抽象構(gòu)件類編程，需要使用具體葉子構(gòu)件類型來定義葉子對象。

??????解決方案二：除此之外，還有一種解決方法是在抽象構(gòu)件AbstractFile中不聲明任何用于訪問和管理成員構(gòu)件的方法，代碼如下所示：

[java]?view plain?copy

abstract?class?AbstractFile?{??

????public?abstract?void?killVirus();??

}??

????? 此時，由于在AbstractFile中沒有聲明add()、remove()等訪問和管理成員的方法，其葉子構(gòu)件子類無須提供實現(xiàn)；而且無論客戶端如何定義葉子構(gòu)件對象都無法調(diào)用到這些方法，不需要做任何錯誤和異常處理，容器構(gòu)件再根據(jù)需要增加訪問和管理成員的方法，但這時候也存在一個問題：客戶端不得不使用容器類本身來聲明容器構(gòu)件對象，否則無法訪問其中新增的add()、remove()等方法，如果客戶端一致性地對待葉子和容器，將會導(dǎo)致容器構(gòu)件的新增對客戶端不可見，客戶端代碼對于容器構(gòu)件無法再使用抽象構(gòu)件來定義，客戶端代碼片段如下所示：

[java]?view plain?copy

class?Client?{??

????public?static?void?main(String?args[])?{??

??????????

????????AbstractFile?file1,file2,file3,file4,file5;??

????????Folder?folder1,folder2,folder3,folder4;?//不能透明處理容器構(gòu)件??

????????//其他代碼省略??

????}??

}??

??????在使用組合模式時，根據(jù)抽象構(gòu)件類的定義形式，我們可將組合模式分為透明組合模式和安全組合模式兩種形式：

????? (1)?透明組合模式

????? 透明組合模式中，抽象構(gòu)件Component中聲明了所有用于管理成員對象的方法，包括add()、remove()以及getChild()等方法，這樣做的好處是確保所有的構(gòu)件類都有相同的接口。在客戶端看來，葉子對象與容器對象所提供的方法是一致的，客戶端可以相同地對待所有的對象。透明組合模式也是組合模式的標(biāo)準(zhǔn)形式，雖然上面的解決方案一在客戶端可以有不透明的實現(xiàn)方法，但是由于在抽象構(gòu)件中包含add()、remove()等方法，因此它還是透明組合模式，透明組合模式的完整結(jié)構(gòu)如圖11-6所示：

圖11-6??透明組合模式結(jié)構(gòu)圖

??????透明組合模式的缺點是不夠安全，因為葉子對象和容器對象在本質(zhì)上是有區(qū)別的。葉子對象不可能有下一個層次的對象，即不可能包含成員對象，因此為其提供add()、remove()以及getChild()等方法是沒有意義的，這在編譯階段不會出錯，但在運行階段如果調(diào)用這些方法可能會出錯（如果沒有提供相應(yīng)的錯誤處理代碼）。

????? (2)?安全組合模式

????? 安全組合模式中，在抽象構(gòu)件Component中沒有聲明任何用于管理成員對象的方法，而是在Composite類中聲明并實現(xiàn)這些方法。這種做法是安全的，因為根本不向葉子對象提供這些管理成員對象的方法，對于葉子對象，客戶端不可能調(diào)用到這些方法，這就是解決方案二所采用的實現(xiàn)方式。安全組合模式的結(jié)構(gòu)如圖11-7所示：

圖11-7??安全組合模式結(jié)構(gòu)圖

?????? 安全組合模式的缺點是不夠透明，因為葉子構(gòu)件和容器構(gòu)件具有不同的方法，且容器構(gòu)件中那些用于管理成員對象的方法沒有在抽象構(gòu)件類中定義，因此客戶端不能完全針對抽象編程，必須有區(qū)別地對待葉子構(gòu)件和容器構(gòu)件。在實際應(yīng)用中，安全組合模式的使用頻率也非常高，在Java AWT中使用的組合模式就是安全組合模式。

總結(jié)

以上是生活随笔為你收集整理的组合模式的安全模式与透明模式的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。