上一次主要介紹了幾個創建型的設計模式AbstractFactroy，FactoryMethod和Singliton。它們的共同的特點，都是用來創建對象的。這次接下來的內容，涉及到的是幾個結構型的模式。所謂結構型模式，就是用來解決在創建系統結構的過程中，通過對類或者對象進行合理有效的組合，以獲得更大的結構的方法。這兒主要講到了Bridge模式和Decorator模式。對於Bridge模式可能需要更多的理解，因爲它在很大程度上說，例示了設計模式的基本的設計思路和原則。
當初Java剛剛推出來的時候，AWT可是一個比較熱的話題，雖然現在有被Swing取代的趨勢。但是我一直都覺得AWT也有其優勢，至少它使用的本地代碼就要比Swing快上許多，而且，可以爲用戶提供熟悉的本地操作系統界面。如果在Windows XP中運行基於AWT的程序的話，XP中絢爛多變的界面Theme可以輕易應用到AWT程序中，而Swing就不行了，因爲AWT所調用的是本帶代碼，使用的是本地的窗體控件。當然，Swing也有其好處，不可一概而論。
簡單來講，AWT提供對程序員的是對窗體界面系統的抽象，而在內部實現中，針對每一種操作系統，分別有不同實現，這就是同位體（Peer）的概念。當程序員調用AWT對象時，調用被轉發到對象所對應的一個Peer上，在由Peer調用本地對象方法，完成對象的顯示。例如，如果你使用AWT創建了一個Menu類的實例，那麼在程序運行時會創建一個菜單同位體的實例，而由創建的同位體的來實際執行菜單的現實和管理。不同的系統，有不同的同位體實現，Solaris JDK將產生一個Motif菜單的同位體，Windows下的JDK將產生一個Windows的菜單的同位體，等等。同位體的使用，使得交叉平臺窗口工具的開發變得極爲迅速，因爲同位體的使用可以避免重新實現本地窗口控件中已經包含的方法。
圖九：AWT中的組件和其對等體
實際上，從設計的角度來看，這是一個抽象和實現分離的過程--AWT是抽象，同位體是實現，抽象和實現各自成爲一個對象體系，它們由一個橋連接起來，可以各自發展各自的對象層次，而不必顧慮另一方面。這就是Bridge模式所提供的思想。Bridge模式更可以提供在各個不同的實現中動態的進行切換，而不必從新編譯程序。
通常，Bridge模式和AbstractFactory模式一起工作，由AbstractFactory來創建一個具體實現的對象體系。特殊的，當只有一個實現的時候，可以將Implementor抽象類去掉。這樣，在抽象和實現之間建立起了一一對應的關係，但這並不損害Bridge模式的內涵。這被稱爲退化了的Bridge模式。
很多時候，Abstraction層次和Implementor層次之間的方法都不是一一對應的，也就是說，在Abstraction和Implementor之不是簡單的的消息轉發。通常，我們會將Abstraction作爲一個抽象類（而不是接口）來實現。在Implementor層次中定義底層的，或者稱之爲原子方法，而在Abstraction層次中定義一些中高層的基於原子方法的抽象方法。這樣，就能更爲清晰的劃分Abstraction和Implementor，類的結構也更爲清晰。
圖十：Bridge模式對系統的劃分
下面，我們來看一個Bridge模式的具體應用。考慮這樣的一個問題，需要生成一份報告，但是報告的格式並沒有確定，可能是HTML文件，也可能是純ASCII文本。報告本身也可能分爲很多種，財務報表，貨物報表，等等問題很簡單，用繼承也較容易實現，因爲相互之間的組合關係並不是很多。但是，我們現在需要用Bridge的觀點來看問題。
在Bridge模式中，使用一個Report類來描敘一個報告的抽象，用一個Reporter類來描敘Report的實現，它的子類有HTMLReporter和ASCIIReporter，用來分別實現HTML格式和ASCII格式的報告。在Report層次下面，有具體的一個StockListReport子類，用來表示貨物清單報告。
public abstract class Report
{
Reporter reporter;
public Report(Reporter reporter) {
this.reporter = reporter;
}
//抽象類使用橋接對象的方法來實現一個任務
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);
}
}
//實現層次的抽象父類定義原子方法，供抽象層次的類調用
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";
}
}實際上，Bridge模式是一個很強大的模式，可以應用在很多方面。其基本思想：分離抽象和實現，是設計模式的基礎之一。正如GOF所提到的："找到變化的部分，並將其封裝起來"；"更多的考慮用對象組合機制，而不是用對象繼承機制"。Bridge模式很好的體現了這幾點。
在使用Java中的IO類庫的時候，是不是快要被它那些功能相似，卻又絕對可稱得上龐雜的類搞得要發瘋了？或許你很不明白爲什麼要做這麼多功能相似的幾十個類出來，這就是Decorator模式將要告訴你的了。
在IO處理中，Java將數據抽象爲流（Stream）。在IO庫中，最基本的是InputStream和OutputStream兩個分別處理輸出和輸入的對象（爲了敘述簡便起見，這兒只涉及字節流，字符流和其完全相似），但是在InputStream和OutputStream中之提供了最簡單的流處理方法，只能讀入/寫出字符，沒有緩衝處理，無法處理文件，等等。它們只是提供了最純粹的抽象，最簡單的功能。
如何來添加功能，以處理更爲複雜的事情呢？你可能會想到用繼承。不錯，繼承確實可以解決問題，但是繼承也帶來更大的問題，它對每一個功能，都需要一個子類來實現。比如，我先實現了三個子類，分別用來處理文件，緩衝，和讀入/寫出數據，但是，如果我需要一個既能處理文件，又具有緩衝功能的類呢？這時候又必須在進行一次繼承，重寫代碼。實際上，僅僅這三種功能的組合，就已經是一個很大的數字，如果再加上其它的功能，組合起來的IO類庫，如果只用繼承來實現的話，恐怕你真的是要被它折磨瘋了。
圖六：JDK中IO流的類層次
Decorator模式可以解決這個問題。Decorator字面的意思是裝飾的意思，在原有的基礎上，每添加一個裝飾，就可以增加一種功能。這就是Decorator的本意。比如，對於上面的那個問題，只需要三個Decorator類，分別代表文件處理，緩衝和數據讀寫三個功能，在此基礎上所衍生的功能，都可以通過添加裝飾來完成，而不必需要繁雜的子類繼承了。更爲重要的是，比較繼機制承而言，Decorator是動態的，可以在運行時添加或者去除附加的功能，因而也就具有比繼承機制更大的靈活性。
上面就是Decorator的基本思想，下面的是Decorator模式的靜態結構圖：
圖七：Decorator模式的類圖
可以看到，一個Decorator與裝飾的Subject對象有相同的接口，並且除了接口中給出的方法外，每個Decorator均有自己添加的方法，來添加對象功能。每個Decorator均有一個指向Subject對象的引用，附加的功能被添加在這個Subject對象上。而Decorator對象本身也是一個Subject對象，因而它也能夠被其他的Decorator所修飾，提供組合的功能。
在Java IO操作中，經常可以看到諸如如下的語句：
myStringBuffer=new StringBuffer("This is a sample string to be read");
FilterInputStream myStream=new LineNumberInputStream
( new BufferInputStream( new StringBufferInputStream( myStringBuffer)));
myStream.read();
myStream.line();不僅僅如此，Java中的IO還允許你引入自定義的Decorator，來實現自己想要的功能。在良好的設計背景下，這做起並不複雜，只需要4步：
- 創建兩個分別繼承了FilterInputStream和 FilterOutputStream的子類
- 重載read()和write()方法來實現自己想要的功能。
- 可以定義或者重載其它方法來提供附加功能。
- 確定這兩個類會被一起使用，因爲它們在功能上是對稱的。
就這樣，你就可以無限的擴展IO的功能了。
在瞭解了IO中的Decorator後，我們再來看一個Decorator模式應用的具體的例子。這個例子原本是出現在GOF書中的，這兒稍作改動，引來示例。
在一個圖形用戶界面（GUI）中，一個組件有時候需要用到邊框或者滾動條，而有時候又不需要，有時候可能兩者都要用到。當需要動態的去處或者添加職能的時候，就可以考慮使用Decorator模式了。這兒對於一個VisualComponent組件對象，我們引入了兩個Decorator類：BoderDecorator和ScrollDecorator，分別用來爲組件添加邊框和處理滾動。程序類圖如下：
圖八：Decorator模式的應用例子
程序寫得很簡單，沒有包括具體的代碼，只是有一個可以運行的框架以供參考。代碼如下：
//Client類用來創建窗體和組件對象，這兒可以看到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類用來容納組件對象
class Window{
VisualComponent contents;
public Window () {}
public void setContents (VisualComponent vc){
contents = vc;
}
}
//VisualComponent類定義了組件的接口
class VisualComponent{
public VisualComponent (){}
public void draw (){}
public void resize (){}
}
//TextView類是一個顯示文本的具體的組件
class TextView extends VisualComponent{
public TextView (){}
public void draw (){
…
}
public void resize (){
…
}
}
//Decorator類繼承於VisualComponent，定義所有Decorator的缺省方法實現
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類爲組件提供邊框
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類爲組件提供滾動條
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確實能夠很好的緩解當功能組合過多時子類繼承所能夠帶來的問題。但是在得到很大的靈活性的同時，Decorator在使用時也表現得較爲複雜。看看僅僅爲了得到一個IO流，除了要創建核心的流外，還要爲其加上各種各樣的裝飾類，這使得代碼變得複雜而難懂。有幾個人一開始時沒有被Java的IO庫嚇一跳呢？
Bridge模式用來分離抽象和實現，使得這兩個部分能夠分別的演化而不必修改另外一部分的內容。通常的，可以在實現部分定義一些基本的原子方法，而在抽象部分則通過組合定義在實現層次中的原子方法來實現系統的功能。Decorator模式通過聚合機制來爲對象動態的添加職責，解決了在子類繼承中容易引起的子類爆炸的問題。