上一次主要介紹了幾個(gè)創(chuàng )建型的設計模式AbstractFactroy，FactoryMethod和Singliton。它們的共同的特點(diǎn)，都是用來(lái)創(chuàng )建對象的。這次接下來(lái)的內容，涉及到的是幾個(gè)結構型的模式。所謂結構型模式，就是用來(lái)解決在創(chuàng )建系統結構的過(guò)程中，通過(guò)對類(lèi)或者對象進(jìn)行合理有效的組合，以獲得更大的結構的方法。這兒主要講到了Bridge模式和Decorator模式。對于Bridge模式可能需要更多的理解，因為它在很大程度上說(shuō)，例示了設計模式的基本的設計思路和原則。
當初Java剛剛推出來(lái)的時(shí)候，AWT可是一個(gè)比較熱的話(huà)題，雖然現在有被Swing取代的趨勢。但是我一直都覺(jué)得AWT也有其優(yōu)勢，至少它使用的本地代碼就要比Swing快上許多，而且，可以為用戶(hù)提供熟悉的本地操作系統界面。如果在Windows XP中運行基于A(yíng)WT的程序的話(huà)，XP中絢爛多變的界面Theme可以輕易應用到AWT程序中，而Swing就不行了，因為AWT所調用的是本帶代碼，使用的是本地的窗體控件。當然，Swing也有其好處，不可一概而論。
簡(jiǎn)單來(lái)講，AWT提供對程序員的是對窗體界面系統的抽象，而在內部實(shí)現中，針對每一種操作系統，分別有不同實(shí)現，這就是同位體（Peer）的概念。當程序員調用AWT對象時(shí)，調用被轉發(fā)到對象所對應的一個(gè)Peer上，在由Peer調用本地對象方法，完成對象的顯示。例如，如果你使用AWT創(chuàng )建了一個(gè)Menu類(lèi)的實(shí)例，那么在程序運行時(shí)會(huì )創(chuàng )建一個(gè)菜單同位體的實(shí)例，而由創(chuàng )建的同位體的來(lái)實(shí)際執行菜單的現實(shí)和管理。不同的系統，有不同的同位體實(shí)現，Solaris JDK將產(chǎn)生一個(gè)Motif菜單的同位體，Windows下的JDK將產(chǎn)生一個(gè)Windows的菜單的同位體，等等。同位體的使用，使得交叉平臺窗口工具的開(kāi)發(fā)變得極為迅速，因為同位體的使用可以避免重新實(shí)現本地窗口控件中已經(jīng)包含的方法。
實(shí)際上，從設計的角度來(lái)看，這是一個(gè)抽象和實(shí)現分離的過(guò)程--AWT是抽象，同位體是實(shí)現，抽象和實(shí)現各自成為一個(gè)對象體系，它們由一個(gè)橋連接起來(lái)，可以各自發(fā)展各自的對象層次，而不必顧慮另一方面。這就是Bridge模式所提供的思想。Bridge模式更可以提供在各個(gè)不同的實(shí)現中動(dòng)態(tài)的進(jìn)行切換，而不必從新編譯程序。
通常，Bridge模式和AbstractFactory模式一起工作，由AbstractFactory來(lái)創(chuàng )建一個(gè)具體實(shí)現的對象體系。特殊的，當只有一個(gè)實(shí)現的時(shí)候，可以將Implementor抽象類(lèi)去掉。這樣，在抽象和實(shí)現之間建立起了一一對應的關(guān)系，但這并不損害Bridge模式的內涵。這被稱(chēng)為退化了的Bridge模式。
很多時(shí)候，Abstraction層次和Implementor層次之間的方法都不是一一對應的，也就是說(shuō)，在A(yíng)bstraction和Implementor之不是簡(jiǎn)單的的消息轉發(fā)。通常，我們會(huì )將Abstraction作為一個(gè)抽象類(lèi)（而不是接口）來(lái)實(shí)現。在Implementor層次中定義底層的，或者稱(chēng)之為原子方法，而在A(yíng)bstraction層次中定義一些中高層的基于原子方法的抽象方法。這樣，就能更為清晰的劃分Abstraction和Implementor，類(lèi)的結構也更為清晰。
下面，我們來(lái)看一個(gè)Bridge模式的具體應用?？紤]這樣的一個(gè)問(wèn)題，需要生成一份報告，但是報告的格式并沒(méi)有確定，可能是HTML文件，也可能是純ASCII文本。報告本身也可能分為很多種，財務(wù)報表，貨物報表，等等問(wèn)題很簡(jiǎn)單，用繼承也較容易實(shí)現，因為相互之間的組合關(guān)系并不是很多。但是，我們現在需要用Bridge的觀(guān)點(diǎn)來(lái)看問(wèn)題。
在Bridge模式中，使用一個(gè)Report類(lèi)來(lái)描敘一個(gè)報告的抽象，用一個(gè)Reporter類(lèi)來(lái)描敘Report的實(shí)現，它的子類(lèi)有HTMLReporter和ASCIIReporter，用來(lái)分別實(shí)現HTML格式和ASCII格式的報告。在Report層次下面，有具體的一個(gè)StockListReport子類(lèi)，用來(lái)表示貨物清單報告。
public abstract class Report { Reporter reporter; public Report(Reporter reporter) { this.reporter = reporter; } //抽象類(lèi)使用橋接對象的方法來(lái)實(shí)現一個(gè)任務(wù) public void addReportItem(Object item){ reporter.addLine(item.toString()); } public void addReportItems(List items){ Iterator iterator = items.iterator(); while ( iterator.hasNext() ) { reporter.addLine(iterator.next().toString()); } } public String report(){ return reporter.getReport(); } } public class StockListReport extends Report{ ArrayList stock=new ArrayList(); public StockListReport(Reporter reporter){ super(reporter); } public void addStockItem(StockItem stockItem){ stock.add(stockItem); addReportItem(stockItem); } } //實(shí)現層次的抽象父類(lèi)定義原子方法，供抽象層次的類(lèi)調用 public abstract class Reporter{ String header = ""; String trailer = ""; String report = ""; public abstract void addLine(String line); public void setHeader(String header){ this.header = header; } public void setTrailer(String trailer){ this.trailer = trailer; } public String getReport(){ return header+report+trailer; } } public class HTMLReporter extends Reporter{ public HTMLReporter(){ setHeader("<HTML>\n<HEAD></HEAD>\n<BODY>\n"); setTrailer("</BODY>\n</HTML>"); } public void addLine(String line){ report += line + "<BR>\n"; } } public class ASCIIReporter extends Reporter{ public void addLine(String line) { report += line + "\n"; } } |
實(shí)際上，Bridge模式是一個(gè)很強大的模式，可以應用在很多方面。其基本思想：分離抽象和實(shí)現，是設計模式的基礎之一。正如GOF所提到的："找到變化的部分，并將其封裝起來(lái)"；"更多的考慮用對象組合機制，而不是用對象繼承機制"。Bridge模式很好的體現了這幾點(diǎn)。
  |
|
在使用Java中的IO類(lèi)庫的時(shí)候，是不是快要被它那些功能相似，卻又絕對可稱(chēng)得上龐雜的類(lèi)搞得要發(fā)瘋了？或許你很不明白為什么要做這么多功能相似的幾十個(gè)類(lèi)出來(lái)，這就是Decorator模式將要告訴你的了。
在IO處理中，Java將數據抽象為流（Stream）。在IO庫中，最基本的是InputStream和OutputStream兩個(gè)分別處理輸出和輸入的對象（為了敘述簡(jiǎn)便起見(jiàn)，這兒只涉及字節流，字符流和其完全相似），但是在InputStream和OutputStream中之提供了最簡(jiǎn)單的流處理方法，只能讀入/寫(xiě)出字符，沒(méi)有緩沖處理，無(wú)法處理文件，等等。它們只是提供了最純粹的抽象，最簡(jiǎn)單的功能。
如何來(lái)添加功能，以處理更為復雜的事情呢？你可能會(huì )想到用繼承。不錯，繼承確實(shí)可以解決問(wèn)題，但是繼承也帶來(lái)更大的問(wèn)題，它對每一個(gè)功能，都需要一個(gè)子類(lèi)來(lái)實(shí)現。比如，我先實(shí)現了三個(gè)子類(lèi)，分別用來(lái)處理文件，緩沖，和讀入/寫(xiě)出數據，但是，如果我需要一個(gè)既能處理文件，又具有緩沖功能的類(lèi)呢？這時(shí)候又必須在進(jìn)行一次繼承，重寫(xiě)代碼。實(shí)際上，僅僅這三種功能的組合，就已經(jīng)是一個(gè)很大的數字，如果再加上其它的功能，組合起來(lái)的IO類(lèi)庫，如果只用繼承來(lái)實(shí)現的話(huà)，恐怕你真的是要被它折磨瘋了。
Decorator模式可以解決這個(gè)問(wèn)題。Decorator字面的意思是裝飾的意思，在原有的基礎上，每添加一個(gè)裝飾，就可以增加一種功能。這就是Decorator的本意。比如，對于上面的那個(gè)問(wèn)題，只需要三個(gè)Decorator類(lèi)，分別代表文件處理，緩沖和數據讀寫(xiě)三個(gè)功能，在此基礎上所衍生的功能，都可以通過(guò)添加裝飾來(lái)完成，而不必需要繁雜的子類(lèi)繼承了。更為重要的是，比較繼機制承而言，Decorator是動(dòng)態(tài)的，可以在運行時(shí)添加或者去除附加的功能，因而也就具有比繼承機制更大的靈活性。
上面就是Decorator的基本思想，下面的是Decorator模式的靜態(tài)結構圖：
可以看到，一個(gè)Decorator與裝飾的Subject對象有相同的接口，并且除了接口中給出的方法外，每個(gè)Decorator均有自己添加的方法，來(lái)添加對象功能。每個(gè)Decorator均有一個(gè)指向Subject對象的引用，附加的功能被添加在這個(gè)Subject對象上。而Decorator對象本身也是一個(gè)Subject對象，因而它也能夠被其他的Decorator所修飾，提供組合的功能。
在Java IO操作中，經(jīng)?？梢钥吹街T如如下的語(yǔ)句：
myStringBuffer=new StringBuffer("This is a sample string to be read"); FilterInputStream myStream=new LineNumberInputStream ( new BufferInputStream( new StringBufferInputStream( myStringBuffer))); myStream.read(); myStream.line(); |
多個(gè)的Decorator被層疊在一起，最后得到一個(gè)功能強大的流。既能夠被緩沖，又能夠得到行數，這就是Decorator的威力！
不僅僅如此，Java中的IO還允許你引入自定義的Decorator，來(lái)實(shí)現自己想要的功能。在良好的設計背景下，這做起并不復雜，只需要4步：
就這樣，你就可以無(wú)限的擴展IO的功能了。
在了解了IO中的Decorator后，我們再來(lái)看一個(gè)Decorator模式應用的具體的例子。這個(gè)例子原本是出現在GOF書(shū)中的，這兒稍作改動(dòng)，引來(lái)示例。
在一個(gè)圖形用戶(hù)界面（GUI）中，一個(gè)組件有時(shí)候需要用到邊框或者滾動(dòng)條，而有時(shí)候又不需要，有時(shí)候可能兩者都要用到。當需要動(dòng)態(tài)的去處或者添加職能的時(shí)候，就可以考慮使用Decorator模式了。這兒對于一個(gè)VisualComponent組件對象，我們引入了兩個(gè)Decorator類(lèi)：BoderDecorator和ScrollDecorator，分別用來(lái)為組件添加邊框和處理滾動(dòng)。程序類(lèi)圖如下：
程序寫(xiě)得很簡(jiǎn)單，沒(méi)有包括具體的代碼，只是有一個(gè)可以運行的框架以供參考。代碼如下：
//Client類(lèi)用來(lái)創(chuàng )建窗體和組件對象，這兒可以看到Decorator是如何組合和應用的 class Client{ public static void main (String[] args ){ Window window = new Window (); TextView textView = new TextView (); window.setContents ( new BorderDecorator ( new ScrollDecorator (textView, 500), 1)); } } //Windows類(lèi)用來(lái)容納組件對象 class Window{ VisualComponent contents; public Window () {} public void setContents (VisualComponent vc){ contents = vc; } } //VisualComponent類(lèi)定義了組件的接口 class VisualComponent{ public VisualComponent (){} public void draw (){} public void resize (){} } //TextView類(lèi)是一個(gè)顯示文本的具體的組件 class TextView extends VisualComponent{ public TextView (){} public void draw (){ … } public void resize (){ … } } //Decorator類(lèi)繼承于VisualComponent，定義所有Decorator的缺省方法實(shí)現 class Decorator extends VisualComponent{ private VisualComponent component; public Decorator (VisualComponent vc) { this.component=vc; } public void draw () { component.draw (); } public void resize () { component.resize (); } } //BorderDecorator類(lèi)為組件提供邊框 class BorderDecorator extends Decorator{ private int width; public BorderDecorator (VisualComponent vc, int borderWidth){ super (vc); width = borderWidth; } public void draw (){ super.draw (); drawBorder (width); } private void drawBorder (int width){ … } } //ScrollDecorator類(lèi)為組件提供滾動(dòng)條 class ScrollDecorator extends Decorator{ private int scrollSize; public ScrollDecorator (VisualComponent vc, int scrSize){ super (vc); scrollSize = scrSize; } public void draw (){ scroll(); super.draw (); } private void scroll (){ … } } |
Decorator確實(shí)能夠很好的緩解當功能組合過(guò)多時(shí)子類(lèi)繼承所能夠帶來(lái)的問(wèn)題。但是在得到很大的靈活性的同時(shí)，Decorator在使用時(shí)也表現得較為復雜?？纯磧H僅為了得到一個(gè)IO流，除了要創(chuàng )建核心的流外，還要為其加上各種各樣的裝飾類(lèi)，這使得代碼變得復雜而難懂。有幾個(gè)人一開(kāi)始時(shí)沒(méi)有被Java的IO庫嚇一跳呢？
聯(lián)系客服
