# 樹形結構的處理——組合模式（四） 11.4 透明組合模式與安全組合模式 通過引入組合模式，Sunny公司設計的殺毒軟件具有良好的可擴展性，在增加新的文件類型時，無須修改現有類庫代碼，只需增加一個新的文件類作為AbstractFile類的子類即可，但是由于在AbstractFile中聲明了大量用于管理和訪問成員構件的方法，例如add()、remove()等方法，我們不得不在新增的文件類中實現這些方法，提供對應的錯誤提示和異常處理。為了簡化代碼，我們有以下兩個解決方案： 解決方案一：將葉子構件的add()、remove()等方法的實現代碼移至AbstractFile類中，由AbstractFile提供統一的默認實現，代碼如下所示： ``` //提供默認實現的抽象構件類 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編程，在調用文件對象的這些方法時將出現錯誤提示。如果不希望出現任何錯誤提示，我們可以在客戶端定義文件對象時不使用抽象層，而直接使用具體葉子構件本身，客戶端代碼片段如下所示： ``` class Client { public static void main(String args[]) { //不能透明處理葉子構件 ImageFile file1,file2; TextFile file3,file4; VideoFile file5; AbstractFile folder1,folder2,folder3,folder4; //其他代碼省略 } } ``` 這樣就產生了一種不透明的使用方式，即在客戶端不能全部針對抽象構件類編程，需要使用具體葉子構件類型來定義葉子對象。 解決方案二：除此之外，還有一種解決方法是在抽象構件AbstractFile中不聲明任何用于訪問和管理成員構件的方法，代碼如下所示： ``` abstract class AbstractFile { public abstract void killVirus(); } ``` 此時，由于在AbstractFile中沒有聲明add()、remove()等訪問和管理成員的方法，其葉子構件子類無須提供實現；而且無論客戶端如何定義葉子構件對象都無法調用到這些方法，不需要做任何錯誤和異常處理，容器構件再根據需要增加訪問和管理成員的方法，但這時候也存在一個問題：客戶端不得不使用容器類本身來聲明容器構件對象，否則無法訪問其中新增的add()、remove()等方法，如果客戶端一致性地對待葉子和容器，將會導致容器構件的新增對客戶端不可見，客戶端代碼對于容器構件無法再使用抽象構件來定義，客戶端代碼片段如下所示： ``` class Client { public static void main(String args[]) { AbstractFile file1,file2,file3,file4,file5; Folder folder1,folder2,folder3,folder4; //不能透明處理容器構件 //其他代碼省略 } } ``` 在使用組合模式時，根據抽象構件類的定義形式，我們可將組合模式分為透明組合模式和安全組合模式兩種形式： (1) 透明組合模式 透明組合模式中，抽象構件Component中聲明了所有用于管理成員對象的方法，包括add()、remove()以及getChild()等方法，這樣做的好處是確保所有的構件類都有相同的接口。在客戶端看來，葉子對象與容器對象所提供的方法是一致的，客戶端可以相同地對待所有的對象。透明組合模式也是組合模式的標準形式，雖然上面的解決方案一在客戶端可以有不透明的實現方法，但是由于在抽象構件中包含add()、remove()等方法，因此它還是透明組合模式，透明組合模式的完整結構如圖11-6所示：  圖11-6 透明組合模式結構圖 透明組合模式的缺點是不夠安全，因為葉子對象和容器對象在本質上是有區別的。葉子對象不可能有下一個層次的對象，即不可能包含成員對象，因此為其提供add()、remove()以及getChild()等方法是沒有意義的，這在編譯階段不會出錯，但在運行階段如果調用這些方法可能會出錯（如果沒有提供相應的錯誤處理代碼）。 (2) 安全組合模式 安全組合模式中，在抽象構件Component中沒有聲明任何用于管理成員對象的方法，而是在Composite類中聲明并實現這些方法。這種做法是安全的，因為根本不向葉子對象提供這些管理成員對象的方法，對于葉子對象，客戶端不可能調用到這些方法，這就是解決方案二所采用的實現方式。安全組合模式的結構如圖11-7所示：  圖11-7 安全組合模式結構圖 安全組合模式的缺點是不夠透明，因為葉子構件和容器構件具有不同的方法，且容器構件中那些用于管理成員對象的方法沒有在抽象構件類中定義，因此客戶端不能完全針對抽象編程，必須有區別地對待葉子構件和容器構件。在實際應用中，安全組合模式的使用頻率也非常高，在Java AWT中使用的組合模式就是安全組合模式。