1、設計模式分解java 六,類似CompositeEquipment, 提供用于訪問自己組合體內的部件方法: 增加 刪除 遍歷. 結合我的其他模式中對Jive的分析，我們已經(jīng)基本大體理解了Jive論壇體系的框架， /*-*/ 結構模式.Decorator Decorator常被翻譯成裝飾,我覺得翻譯成油漆工更形象點,油漆工(decorator)是用來刷油漆的, 那么被刷油漆的對象我們稱decoratee.這兩種實體在Decorator模式中是必須的. Decorator定義: 動態(tài)給一個對象添加一些額外的職責,就象在墻上刷油漆. 使用Decorator模式相比用生成子類方式達到功能的擴充顯得更為

2、靈活. 為什么使用Decorator? 我們通?？梢允褂美^承來實現(xiàn)功能的拓展,如果這些需要拓展的功能的種類很繁多, 那么勢必生成很多子類,增加系統(tǒng)的復雜性,同時,使用繼承實現(xiàn)功能拓展, 我們必須可預見這些拓展功能,這些功能是編譯時就確定了,是靜態(tài)的.,使用Decorator的理由是:這些功能需要由用戶動態(tài)決定加入的方式和時機. Decorator提供了即插即用的方法,在運行期間決定何時增加何種功能. 如何使用? 舉Adapter中的打樁示例,在Adapter中有兩種類:方形樁 圓形樁, Adapter模式展示如何綜合使用這兩個類,在Decorator模式中, 我們是要在打樁時增加一些額外功能,

3、比如,挖坑 在樁上釘木板等,不關心如何使用兩個不相關的類. 我們先建立一個接口: public interface Work public void insert(); 接口Work有一個具體實現(xiàn):插入方形樁或圓形樁,這兩個區(qū)別對Decorator是無所謂.我們以插入方形樁為例:,public class SquarePeg implements Work public void insert() System.out.println(方形樁插入); 現(xiàn)在有一個應用:需要在樁打入前,挖坑,在打入后,在樁上釘木板,這些額外的功能是動態(tài), 可能隨意增加調整修改,比如,可能又需要在打樁之后釘架子(只

4、是比喻). 那么我們使用Decorator模式,這里方形樁SquarePeg是decoratee(被刷油漆者), 我們需要在decoratee上刷些油漆,這些油漆就是那些額外的功能. public class Decorator implements Work private Work work; /額外增加的功能被打包在這個List中,private ArrayList others = new ArrayList(); /在構造器中使用組合new方式,引入Work對象; public Decorator(Work work) this.work=work; others.add(挖坑);

5、others.add(釘木板); public void insert() newMethod(); ,/在新方法中,我們在insert之前增加其他方法,這里次序先后是用戶靈活指定的 public void newMethod() otherMethod(); work.insert(); public void otherMethod() ListIterator listIterator = others.listIterator(); while (listIterator.hasNext() System.out.println(String)(listIterator.next()

6、+ 正在進行); , 在上例中,我們把挖坑和釘木板都排在了打樁insert前面,這里只是舉例說明額外功能次序可以任意安排. 好了,Decorator模式出來了,我們看如何調用: Work squarePeg = new SquarePeg(); Work decorator = new Decorator(squarePeg); decorator.insert(); Decorator模式至此完成. 如果你細心,會發(fā)現(xiàn),上面調用類似我們讀取文件時的調用: FileReader fr = new FileReader(filename); BufferedReader br = new Buf

7、feredReader(fr); 實際上Java 的I/O API就是使用Decorator實現(xiàn)的,I/O變種很多, 如果都采取繼承方法,將會產(chǎn)生很多子類,顯然相當繁瑣. Jive中的Decorator實現(xiàn),在論壇系統(tǒng)中,有些特別的字是不能出現(xiàn)在論壇中如打倒XXX,我們需要過濾這些反動的字體. 不讓他們出現(xiàn)或者高亮度顯示. 在IBM Java專欄中專門談Jive的文章中,有談及Jive中ForumMessageFilter.java使用了Decorator模式, 其實,該程序并沒有真正使用Decorator,而是提示說:針對特別論壇可以設計額外增加的過濾功能, 那么就可以重組ForumMess

8、ageFilter作為Decorator模式了. 所以,我們在分辨是否真正是Decorator模式,以及會真正使用Decorator模式,一定要把握好Decorator模式的定義,以及其中參與的角色(Decoratee 和Decorator). /*-*/ 結構模式.Bridge Bridge定義 : 將抽象和行為劃分開來,各自獨立,但能動態(tài)的結合. 為什么使用? 通常,當一個抽象類或接口有多個具體實現(xiàn)(concrete subclass),這些concrete之間關系可能有以下兩種: 1. 這多個具體實現(xiàn)之間恰好是并列的,如前面舉例,打樁,有兩個concrete class:方形樁和圓形樁;

9、 這兩個形狀上的樁是并列的,沒有概念上的重復,那么我們只要使用繼承就可以了. 2.實際應用上,常常有可能在這多個concrete class之間有概念上重疊.,那么需要我們把抽象共同部分和行為共同部分各自獨立開來, 原來是準備放在一個接口里,現(xiàn)在需要設計兩個接口,分別放置抽象和行為. 例如,一杯咖啡為例,有中杯和大杯之分,同時還有加奶 不加奶之分. 如果用單純的繼承,這四個具體實現(xiàn)(中杯 大杯 加奶 不加奶)之間有概念重疊, 因為有中杯加奶,也有中杯不加奶, 如果再在中杯這一層再實現(xiàn)兩個繼承,很顯然混亂,擴展性極差. 那我們使用Bridge模式來實現(xiàn)它. 如何實現(xiàn)? 以上面提到的咖啡 為例.

10、我們原來打算只設計一個接口(抽象類),使用Bridge模式后, 我們需要將抽象和行為分開,加奶和不加奶屬于行為,我們將它們抽象成一個專門的行為接口. 先看看抽象部分的接口代碼:,public abstract class Coffee CoffeeImp coffeeImp; public void setCoffeeImp() this.CoffeeImp = CoffeeImpSingleton.getTheCoffeImp(); public CoffeeImp getCoffeeImp() return this.CoffeeImp; public abstract void pour

11、Coffee(); 其中CoffeeImp 是加不加奶的行為接口,看其代碼如下: public abstract class CoffeeImp, public abstract void pourCoffeeImp(); 現(xiàn)在我們有了兩個抽象類,下面我們分別對其進行繼承,實現(xiàn)concrete class: /中杯 public class MediumCoffee extends Coffee public MediumCoffee() setCoffeeImp(); public void pourCoffee() CoffeeImp coffeeImp = this.getCoffeeI

12、mp(); /我們以重復次數(shù)來說明是沖中杯還是大杯 ,重復2次是中杯 for (int i = 0; i 2; i+) ,coffeeImp.pourCoffeeImp(); /大杯 public class SuperSizeCoffee extends Coffee public SuperSizeCoffee() setCoffeeImp(); public void pourCoffee() CoffeeImp coffeeImp = this.getCoffeeImp(); /我們以重復次數(shù)來說明是沖中杯還是大杯 ,重復5次是大杯 for (int i = 0; i 5; i+), coffeeImp.pourCoffeeImp(); 上面分別是中杯和大杯的具體實現(xiàn).下面再對行為CoffeeImp進行繼承: /加奶 public class MilkCoffeeImp extends CoffeeImp MilkCoffeeImp() public v