成人亚洲一区二区,国产在线播放精品,国产一级免费在线观看

Design Pattern: Decorator 模式

Tue, 17 Apr 2007 02:44:00 GMT

在Java Swing中的JTextArea元�g預設並沒有捲軸，因為�a�計人員認為捲軸的功能並不是一定需要的�Q�而決定讓�E�式人員可以動態選擇是否增加捲軸功能�Q�捲軸的功能是由JScrollPane元�g提供�Q�如果您要加入一個具有捲軸功能的JTextArea�Q�您可以如下進行�a�計�Q?br>

JTextArea textArea = new JTextArea();
JScrollPane scrollPane = new JScrollPane(textArea);

JScrollPane��JTextArea��x��個容器，而它��JFrame來說又是個元�Ӟ��可以如下這般��之加入JFrame中：

getContentPane().add(scrollPane);

像這樣動態的為JTextArea加入功能的方法，我們可以��用Decorator模式來組�J�結構，您可以動態的��Z��個物件加入一些功能（像是�?JTextArea加上捲軸�Q�，而又不用修改JTextArea的功能。對JTextArea來說�Q�JScrollPane��好像是一個捲軸外框，直接套在JTextArea上作裝飾�Q�就好比您在照片上加上一個相框的意思�?br>
先以上面這個例子來說明Decorator模式的一個實例：

如上圖所�C�的�Q�無論是TextView或是Decorator��別�Q�它們都是VisualComponent的一個子��，也就是說它們都是一個可視元�Ӟ��而Decorator��又聚合了VisualComponent�Q�所以又可以當作TextView容器�Q�ScrollDecorator��別實作�?Decorator��，它可能是這樣�a�計的：

public abstract class Decorator extends VisualComponent {
    protected VisualComponent component;

    public Decorator(VisualComponent component) {
        this.component = component;
    }

    public void draw() {
        component.draw();
    }
}

public class ScrollDecorator extends Decorator {
    public ScrollDecorator(VisualComponent component) {
        super(component);
    }

    public void draw() {
        super.draw();
        scrollTo();
    }

    public void scrollTo() {
        // ....
    }
}

要將新功能套用至TextView上，可以這樣�a�計�Q?br>

ScrollDecorator scrollDecorator =
new ScrollDecorator(new TextView());

super.draw()會先呼叫component也就是TextView物�g的draw()�Ҏ��先繪製TextView�Q�然後再進行 ScrollPanel的scrollTo()�Q�也��是捲動的方法。在圖中也表�C�Z��一個BorderDecorator�Q�它可能是這樣�a�計的：

public class BorderDecorator extends Decorator {
    public BorderDecorator(VisualComponent component) {
        super(component);
    }

    public void draw() {
        super.draw();
        drawBorder();
    }

    public void drawBorder() {
        // ....
    }
}

要將ScrollDecorator與BorderDecorator加至TextView上，我們可以這樣�a�計�Q?br>

BorderDecorator borderDecorator =
new BorderDecorator(
new ScrollDecorator(new TextView()));

所以當BorderDecorator調用draw()�Ҏ��時，它會先調用ScrollDecorator的draw()�Ҏ��Q��?ScrollDecorator的draw()�Ҏ��又會先調用TextView的draw()�Ҏ��Q�所以繪製的順序變成�Q?br>

TextDraw.draw();
ScrollDecorator.scrollTo();
BorderDecorator.drawBorder();

下圖為物件之間的調用關係�Q?br>

Decorator模式�?UML �i�構圖如下所�C�：

在Gof的書中指出另一個範例，它設�a�一個Stream抽象��，而有一個StreamDecorator��，Stream的子��有處理�a�憶體串��的 MemoryStream與FileStream�Q�有各種�Ҏ��可以處理串流�Q�也�a�只是單純的處理字元�Q�也�a�會進行壓縮�Q�也�a�會進行字元轉換�Q�最基本的處理可能是處理字元�Q�而字元壓�^�被視為��外的功能，這個時候我們可以��用裝飾模式，在需要的時候為Stream物�g加上必要的功能，事實上在java.io中的�a�多輸入輸出物�g�Q�就是採取這樣的設�a��?br>

张金�?/a> 2007-04-17 10:44 发表评论

Design Pattern: Flyweight 模式

Tue, 17 Apr 2007 02:44:00 GMT

�?Gof 的書中指出，Flyweight的目的在於運用共享技術，使得一些細�_�度的物件可以共享�?br>
Flyweight在牛�z�字�怸�的解釋是"boxer of the lightest class"。意思是特輕量級��x��手？其實應該是取"the lightest class"這部份的解釋�Q�一個特輕量級類別，這個類別所產生的物件可以共用在每一個場合（context�Q�，並依場合資訊表現物�g外觀�?br>
在書中所舉出的例子是文檔�R�輯器中的字元物�Ӟ��若每個字元物件會包括字元、大��、字型等�{�不同的資訊�Q�想想一��文章中可能出現多少字元�Q�如果我們為每一個字元都使用一個物件來完整描述有關於它的訊息，那麼一��文字中��會耗用多少的記憉��Q�！字元本��n應可以共享，而大��、字型等�{�不同的資訊再分別設定�?br>
考慮敔R��多且性質相近的物件時�Q�將該物件的資訊分為兩個部份：內部狀態（intrinsic�Q�與外部狀態（extrinsic�Q�。以上例來說�Q�字元屬於內部狀態，而大��、字型等�{�不同的資訊屬於外部狀態�?br>
更詳��C��些來說明�Q�內部狀態是物�g可共享的�a�息部䆾�Q�例如在�J�製一個英文字串時�Q�重覆的字元部䆾為內部狀態，像是 "ABC is BAC"�Q�其中A、B、C的字元資�a�部份不必直接儲存於字元物�g中，它是屬於可以�׃�n的部份，可以��這些可以重複使用的字元儲存在Flyweight Pool中�?br>
外部狀態是物�g依賴的一個場景（context�Q�，例如�J�製字元時的字型資訊、位�|�資�a�等�{�，�J�製一個字元時�Q�先從Flyweight Pool中找出共享的Flyweight�Q�然後從場景中查扑ְ�應的�J�製資訊�Q�字型、大��、位�|�等�Q��?br>
其實��M��孔R��Java的�h��׃��定��用過Java中運用Flyweight模式的好處，要知道，如果您在�E�式中��用下面的方式來宣告，則實際上是指向同一個字串物�Ӟ��

String str1 = "flyweight";
String str2 = "flyweight";
System.out.println(str1 == str2);

�E�式的執行結果會��示True�Q�在Java中，會維護一個String Pool�Q�對��g��些可以共享的字串物�g�Q�會先在String Pool中查找是否存在相同的String內容�Q�字元相同）�Q�如果有��q��接傳回，而不是直接創造一個新的String物�g�Q�以減少�a�憶體的耗用�?br>
再來個一看例子，String的intern()�Ҏ��Q�我們來看看它的API說明的節錄：

Returns a canonical representation for the string object.

A pool of strings, initially empty, is maintained privately by the class String.

When the intern method is invoked, if the pool already contains a string equal to this String object as determined by the equals(Object) method, then the string from the pool is returned. Otherwise, this String object is added to the pool and a reference to this String object is returned.

這段話其實已說明了Flyweight模式的運作方式，用個實例來說明會更清楚�Q?br>

Main.java

public class Main { 
    public static void main(String[] args) { 
        String str1 = "fly"; 
        String str2 = "weight"; 
        String str3 = "flyweight"; 
        String str4; 

        str4 = str1 + str2; 
        System.out.println(str3 == str4); 

        str4 = (str1 + str2).intern(); 
        System.out.println(str3 == str4); 
    } 
}

在程式中�W�一�ơ比較str3與str4物�g是否為同一物�g時，您知道結果會是false�Q�而intern()�Ҏ��會先檢查 String Pool中是否存在字元部份相同的字串物�g�Q�如果有的話��傳回，由於�E�式中之前已�E�有"flyweight"字串物�g�Q�intern()在String Pool中發現了它，所以直接傳回，這時再進行比較�Q�str3與str4所指向的其實是同一物�g�Q�所以結果會是true�?br>
Flyweight模式在傳回物件時�Q�所使用的是工廠模式�Q��用者並不會知道物�g被創造的細節�Q�下圖是Flyweight模式的結構圖�Q?

之前舉的例子是針��物件的內部狀態所作的說明�Q�那麼字型資�a�等外部的設定呢�Q�一兩個簡單的外部資訊�a�定可以直接寫死�Q�hard code�Q�在�E�式中，例如��單的��用介面字型設定�?br>
但如果是文書處理器呢�Q��用者設定字型、大��等資訊會是動態的呢�Q�Gof�怸��字型資�a�作為是�J�製字元的外部狀態，使用一個Context 物�g來維護外部狀態資料��n�Q�每�ơ要�J�製字元物�g時，這個Context物�g會被作為參數傳遞�i�字元物�Ӟ��字元物�g透過查找Context中的資料來獲得字型資�a�，從而進行正確的場景繪製�?br>
外部狀態維譯��內部狀態之間的��應關係�Q�在查找時，Gof�怸�所使用的是BTree?�i�構�Q�由於查扑ֿ�須花��L��間，所以這也指出了��用Flyweight 模式所必須付出的代價：以時間換取空間。如何設�a�外部狀態的資料�i�構�Q�以使得查找時間�^�短�Q�這是另一個重要的課題�Q�不過就不是這篇文章要討論的課題了）�?br>
補充�Q�關於字元（內部狀態）及字型、大��（外部狀態）之間的對應問��通常不太需要程式設�a��h員的關心�Q�因為通常可以扄��C��些現成的圖型介面API�Q�它們都�a�計好一些相關元�Ӟ��直接使用��可以了�?br>

张金�?/a> 2007-04-17 10:44 发表评论

Design Pattern: Bridge 模式

Tue, 17 Apr 2007 02:42:00 GMT

�?Gof 的書中指到Bridge模式的目的：「將抽象部䆾與它的實��N��份分離，使它們都可以獨立地變化。�?br>
這句話寫得簡短，這邊再作進一步的解釋�Q�抽象部份指的是行為斚w��定義�Q�實現方面指的是與特定��^台相依的代碼實現�?br>
一個實際的例子在Gof�怸�有提刎ͼ�假設您定��了一個IWindow介面�Q�這個介面只定義一些抽象的�J�圖行為�Q�而不涉及�q�_��的實作，今天您可以繼扉K��個類來開發適用於X Window的XWindow��，也可以繼扉K��個類來開發適用於Windows XP�pȝ��的WindowsXP��，��Z��善用�pȝ��資源�Q�您在實作IWindow介面時，會將與系�i�q��關的實現代碼撰寫在介面的實作中�?br>

假設今天您繼承了IWindow介面撰寫了一個I3DWindow介面�Q�當中擴充一個drawBox()�Ҏ��用於3D圖�Ş的繪製，��單的說�Q?I3DWindow介面擴充了抽象行為，��Z��讓實現I3DWindow的類別也能在XWindow與Windows XP兩個不同的�pȝ��中運行，您必須再度撰寫與�pȝ��盔R��的實現代��{�?br>

��單的說�Q�抽象行為定��與�q�_��盔R��實現混雜在一起了�Q�為了將抽象部䆾與它的實��N��份分離，使它們都可以獨立地變化，您可以��用以下的�i�構�?br>

在上圖的右邊中，與��^台相關的實現部䆾�Q�被與右邊抽象行斚w��的發展分開了�Q�左邊的抽象部䆾您可以一直發展下去，而不再因為綁定了�q�_��特定實作�Ҏ��Q�而��得整個結構越來越失去彈性�?br>
Bridge模式�?UML ��別�i�構圖如下：

张金�?/a> 2007-04-17 10:42 发表评论

Design Pattern: Composite 模式

Tue, 17 Apr 2007 02:42:00 GMT

如果以繪圖為例的話，一個文字是一個繪圖元�Ӟ��一個線�D�|��一個繪圖元�Ӟ��而一個長方�Ş也是一個繪圖元�Ӟ��這些�J�圖元�g可以�i�成一個圖片，如果��這個圖片也視作一個繪圖元�Ӟ��則這麼遞迴�J�圖下去�Q�就可以�i�合成一個較大的、複雜的圖�Ş元�g�Q�這樣的目的可以��用Composite模式來解決�?br>
��於使用者而言�Q�無論是文字、線�D�|��h��形，甚至是組合後的圖片元�Ӟ��它們都擁有一個共同的行為�Q��用者基本上並不會感覺出它們之間的操作有�Q何的不同�Q�您可以拖曳、放大、縮��等�{�，這些行為都是一致的�?br>
�?UML 來表�C�Z��面這個例子的�i�構�Q?

��於Text、Line與Rectangle而言�Q�Picture是一個容器，然而Picture�J�承Graphic��，所以它也是一個繪圖元�Ӟ��您可以進一步的��Picture�i�合臛_��一個Picture中，以�Ş成較大的、複雜的圖�Ş�?br>
�i�合模式的UML�i�構圖如下所�C�：

依此架構�Q�您可以遞迴的組合圖形元�Ӟ��例如�Q?br>

除了�J�圖元�g之外�Q�一些具有層�ơ性或�i�合性的物�g也可以��用Composite模式�Q�像是電路元件、設備元件等�{�，使用Composite模式可以大大減低這些元�g�a�計的複雜度�?br>

张金�?/a> 2007-04-17 10:42 发表评论

Design Pattern: Adapter 模式 - Object Adapter

Tue, 17 Apr 2007 02:41:00 GMT

您的電腦是個舊電腦�Q�新的滑鼠都在��用USB接口了，而您的電腦上並沒有USB�Q�而只有一個PS2接口�Q�這時您可以��用一個USB轉PS2的接頭作��換，這樣您的電腦��可以��用新滑鼠了（當然您也可以使用USB擴充卡，意思是相同的）�?br>
��似的概念，有時候您惛_��原來的程式中加入一個外部元�Ӟ��例如一個類別，但是這個類別與您目前所�a�計的程式在介面上並不一��_��Z��讓這個外部類與原�E�式的介面一��_��您必須��用一個類別作��Z��介來配接它們，這時您可以採用Adapter模式�?br>
舉個例子來說，在Java 1.0中有個Enumeration�Q�您在這個版本發行之後，使用它來�a�計了一個MessageApplication�Q�例如：

MessageApplication.java

import java.util.*;

public class MessageApplication {
    public void showAllMessage(Enumeration enum) {
        Object msg;
        while(enum.hasMoreElements()) { 
            msg = enum.nextElement();
            System.out.println(msg);
        }
    }     
}

您的客戶端程式是這麼使用MessageApplication的：

MessageClient.java

import java.util.*;

public class MessageClient {
    private MessageApplication msgApp;

    public void run() {
        Vector vector = new Vector();
        for(int i = 0; i < 10; i++)
            vector.addElement("物�g " + i);
        
        msgApp = new MessageApplication();
        msgApp.showAllMessage(vector.elements());
    }
    
    public static void main(String[] args) {
        MessageClient msgClient = new MessageClient();
        msgClient.run();
    }
}

珑֜�Java 1.2中新增了Iterator�Q�您惌��使用它的功能�Q�但基本上您不想更動原來�E�式中已�a�計好的MessageApplication��別�Q�這時候您可以使用Adapter模式�Q�將Iterator的介面轉換為Enumeration相容�Q�例如：

IteratorAdapter.java

import java.util.*;

public class IteratorAdapter implements Enumeration {
    private Iterator iterator;

    IteratorAdapter(Iterator iterator) {
        this.iterator = iterator;   
    }

    // 轉接介面
    public boolean hasMoreElements() {
        return iterator.hasNext();
    }

    public Object nextElement() 
                        throws NoSuchElementException {
        return iterator.next();
    } 
}

您可以在客戶端程式中照樣使用MessageApplication��別�Q�而不用作��M��的變動：

MessageClient.java

import java.util.*;

public class MessageClient {
    // We could still use MessageApplication
    private Enumeration iteratorAdapter;
    
    public void run() {
        List arrayList = new ArrayList();

        for(int i = 0; i < 10; i++)
            arrayList.add("物�g " + i);
        
        iteratorAdapter = 
               new IteratorAdapter(arrayList.iterator());
        // We could still use MessageApplication
        MessageApplication msgApp = new MessageApplication();       
        msgApp.showAllMessage(iteratorAdapter);
    }

    public static void main(String[] args) {
        MessageClient msgClient = new MessageClient();
        msgClient.run();
    }
}

如程式所�C�的�Q�透過Adapter模式�Q�您原有�E�式中已�a�計好的��別不用更動�Q�就可以引進新��別的功能，��上面的�E�式UML��別�i�構畫出如下�Q?br>

上面的作法，是將要引進的新類別當作Adapter��別的一個物件成員，這是IbObject Adapter模式�Q�其抽象�i�構如下�Q?br>

张金�?/a> 2007-04-17 10:41 发表评论

Design Pattern: Adapter 模式 - Class Adapter

Tue, 17 Apr 2007 02:41:00 GMT

Adapter模式的另一�E�作法是Class Adapter模式�Q�在這個模式下�Q�Adapter直接�J�承Adaptee�Q�要引進的新類別）�Q�以擁有當中的成員及�Ҏ��Q�在C++中的話可以這麼作：

C++中可以多重繼承，但在Java中不行，所以在Java中若要採用Class Adapter�Q�必須作點修改，一斚w��J�承Adaptee�Q�一斚w��實作Target的介面：

代碼的實現是這樣的：

public class Adapter extends Adaptee implements Target {
// ....
}

當然�Q�這必須您原先的Target定義了共同的介面�Q�所以Class Adapter在Java中適用的場合較少�Q�事實上�Q�也比較��使用Object Adapter�Q�這樣的Adapter模式比較有彈性，例如�Q�您可以在Adapter上加上個setter�Q�以隨時可以抽換Adaptee�?br>
在Java中，Class Adapter的一個應用場合是達到多重�J�承的效果，您一定在很多時候聽別�h說，介面�Q�interface�Q�可以達到多重繼承的效果�Q�這是怎麼回事�Q?br>
其實要討論這個問��，首先您對於C++中多重繼承要先有認識�Q�新手看了書說介面可以達到多重繼承，切莫��Z��亦云�Q�尤其是沒有孔R��C++的新手們，如果您對於C++多重�J�承惌��有所認識�Q�請先看�?多重�J�承�Q�一�Q?/a>�?多重�J�承�Q�二�Q?/a>�?br>
Java不能多重�J�承�Q�但��Z��說Java中可以��用介面（interface�Q�來達到多重�J�承的效果，首先效果之一�Q�就�?多重�J�承�Q�二�Q?/a> 中描�q�的「多重繼承時通常其中一個基底類別作為private實作體，而其它的用以表現完全的抽象介面。」，在Java中這個效果可以��用介面來達到�Q�介面此時所扮演的即多重�J�承�Q�二�Q?/a> 中的抽象��別�Q�一個完全的抽象介面�Q�這個效果的達成方式�Q�如介面�Q�interface�Q�型�?/a> 中所介紹的，您可以直接對應這兩個主��中的程式實作來瞭解�Q�瞭解Java中如何��用介面（interface�Q�來達到C++中所��多重繼承的「一�E�」效果�?br>
來看看另一個情況�?br>
如果有SomeClass��別與OtherClass��別�Q�您惌��SomeAndOther��別可以同時擁有SomeClass��別�?OtherClass��別中已定義好的操作�Q�並可以進行多型操作�Q�在C++中可以用多重�J�承來達刎ͼ�但在Java中顯然的無法使用多重�J�承�Q�怎麼辦？您可以在�a�計上先�J�個彎�Q�先使用兩個介面分別定��好SomeClass與OtherClass兩個類別的公開�Ҏ��Q�例如：

public interface ISome {
public void doSome();
}

public interface IOther {
public void doOther();
}

接著讓SomeClass與OtherClass分別實作兩個介面：

public class SomeClass implements ISome {
    public void doSome() {
        ....
    }
}

public class OtherClass implements IOther {
public void doOther() {
....
}
}

SomeAndOther如何同時擁有兩個SomeClass與OtherClass��別已定��好的操作？並可以多型操作？SomeAndOther可以�J�承其中之一�Q�並擁有其中之一�Q�例如：

public class SomeAndOther extends SomeClass implements IOther {
private IOther other = new OtherClass();

public void doOther() {
other.doOther();
}
}

雖不滿意�Q�但臛_��解決了目前的問題�Q�當焉��邊只是其中一例，畢竟C++是C++�Q�Java是Java�Q�兩者語法並不是一��一的關係，視實際需求還可以變化一下�?br>

张金�?/a> 2007-04-17 10:41 发表评论

Design Pattern: Default Adapter 模式

Tue, 17 Apr 2007 02:40:00 GMT

在Java中如果要定義事�g處理的方式，必須實作EventListener的子介面�Q�例如實�?WindowListener來定��一些視�H�事件的處理方式�Q�WindowListener中定��了七個方法：

public interface WindowListener extends EventListener {
    public void windowOpened(WindowEvent e);
    public void windowClosing(WindowEvent e);
    public void windowClosed(WindowEvent e);
    public void windowIconified(WindowEvent e);
    public void windowDeiconified(WindowEvent e);
    public void windowActivated(WindowEvent e);
    public void windowDecativated(WindowEvent e);
}

可以定義一個類別來實作這個介面，以完全想要的事�g處理�Q�例如：

public class WindowEventHandler implements WindowListener {
    public void windowOpened(WindowEvent e) {}
    public void windowClosing(WindowEvent e) {}

    public void windowClosed(WindowEvent e) {
        System.exit(0);
    }

    public void windowIconified(WindowEvent e) {}
    public void windowDeiconified(WindowEvent e) {}
    public void windowActivated(WindowEvent e) {}
    public void windowDecativated(WindowEvent e) {}
}

然而這有個缺點，實作介面的原則是您必須實作當中所定義的所有方法，即��您對某些事�g並不感興��，您也必須實作一個沒有內容的�I�方法，代表您已�E�實作了介面中定��的�Ҏ��Q�然而有時，您並不知道介面中到底定義了幾個方法，或是知道也不知道�Ҏ��的確切名�E�p��參數�Q�即使您查了API�Q�在�E�式中寫下一堆沒有實作內容的�Ҏ��也是很煩人的一件事�?br>
WindowAdapter��別預先實作了WindowListener介面�Q�每個方法中都是�I�的實作�Q�如下所�C�：

public abstract class WindowAdapter
                         implements WindowListener {
    public void windowOpened(WindowEvent e) {}
    public void windowClosing(WindowEvent e) {}
    public void windowClosed(WindowEvent e) {}
    public void windowIconified(WindowEvent e) {}
    public void windowDeiconified(WindowEvent e) {}
    public void windowActivated(WindowEvent e) {}
    public void windowDecativated(WindowEvent e) {}
}

可以�J�承WindowAdapter��別�Q�並重新定義一些您所感興��的事�g�Q�如此一來，��可以避開之前所提及的，直接實作 WindowListener介面的缺點，如下所�C�：

public class WindowEventHandler extends WindowAdapter {
    public void windowClosed(WindowEvent e) {
        System.exit(0);
    }
}

這就是Default Adapter模式�Q�它使用一個中介的Adapter��別來將真正感興��的事�g實作��別�Q�配接至事�g處理介面�Q�上面的�E�式�?UML 圖如下：

��上圖一般化�Q�Default Adapter模式的結構如下所�C�：

张金�?/a> 2007-04-17 10:40 发表评论

Tue, 17 Apr 2007 02:38:00 GMT

延續 Proxy模式�Q�一�Q?/a> 的議��，來看看實現代理的兩種方式�Q�Static Proxy與Dynamic Proxy。嚴��g��說這是屬於模式的實現方式，不過藉由實例可以更瞭解Proxy模式的應用�?br>
先來看個例子，這個例子是�a�錄�Q�log�Q�動作，�E�式中很帔R��要為某些動作或事件作下記錄，以便在事後檢視或是作為除錯時的資�a�，一個最��單的例子如下：

HelloSpeaker.java

import java.util.logging.*; 

public class HelloSpeaker { 
    private Logger logger = 
               Logger.getLogger(this.getClass().getName()); 

    public void hello(String name) { 
        logger.log(Level.INFO, "hello method starts....");

        System.out.println("Hello, " + name); 

        logger.log(Level.INFO, "hello method ends...."); 
    } 
}

HelloSpeaker在執行hello()�Ҏ��時，您希望能�a�錄該方法已�E�執行及�i�束�Q�最��單的作法就是如上在埯��的前後加上記錄動作，然�?Logger介入了HelloSpeaker中，�a�錄這個動作並不屬於HelloSpeaker�Q�這��得HelloSpeaker增加了非業務上需要的邏輯在當中�?br>
��x��如果�E�式中這種�a�錄的動作到處都有需求，上面這種寫法勢必造成必須複製�a�錄動作的程式碼�Q��得維譯��錄動作的困難度加大。如果不只有�a�錄動作�Q�有一些非物�g本��n聯��K的相關動作也混入了物件之中（例如�Ɗ限檢查、事務管理等�{�）�Q�會使得物�g的負擔更形加重，甚至��h��了物件的聯��K�Q�物件本�w�的聯��K所佔的�E�式��|��或許遠小於這些與物件職責不盔R��動作的程式碼�?br>
怎麼辦，用下面的�Ҏ��或許好一些，先定��一個介面，然後實作該介面：

IHello.java

public interface IHello { 
    public void hello(String name); 
}

HelloSpeaker.java

public class HelloSpeaker implements IHello { 
    public void hello(String name) { 
        System.out.println("Hello, " + name); 
    } 
}

接下來實作一個代理物件HelloProxy�Q?br>

HelloProxy.java

import java.util.logging.*; 

public class HelloProxy implements IHello { 
    private Logger logger = 
              Logger.getLogger(this.getClass().getName()); 
    private IHello helloObject; 

    public HelloProxy(IHello helloObject) { 
        this.helloObject = helloObject; 
    } 

    public void hello(String name) { 
        logger.log(Level.INFO, "hello method starts...."); 

        helloObject.hello(name); 

        logger.log(Level.INFO, "hello method ends...."); 
    } 
}

埯��時可以如此：

IHello helloProxy = new HelloProxy(new HelloSpeaker());
helloProxy.hello("Justin");

代理物�gHelloProxy��代理真正的HelloSpeaker來執行hello()�Q�並在其前後加上�a�錄的動作，這��?HelloSpeaker在撰寫時不必介入�a�錄動作�Q�HelloSpeaker可以��心於它的職責�?br>
這是Static Proxy的基本範例，然而如您所看到的，代理物�g的一個介面只服務��g��E�類型的物�g�Q�而且如果要代理的�Ҏ��很多�Q�勢必要為每個方法進行代理�Q?Static Proxy在程式規模稍大時��必定無法勝仅R�?br>
Java在JDK 1.3之後加入協助開發Dynamic Proxy功能的類別，我們不必為特定物�g與方法撰寫特定的代理�Q��用Dynamic Proxy�Q�可以��得一個handler服務於各個物�Ӟ��首先�Q�一個handler必須實現 java.lang.reflect.InvocationHandler�Q?

LogHandler.java

import java.util.logging.*; 
import java.lang.reflect.*; 

public class LogHandler implements InvocationHandler { 
    private Logger logger = 
               Logger.getLogger(this.getClass().getName()); 
    private Object delegate; 

    public Object bind(Object delegate) { 
        this.delegate = delegate; 
        return Proxy.newProxyInstance(
                 delegate.getClass().getClassLoader(), 
                 delegate.getClass().getInterfaces(), 
                 this); 
    }
 
    public Object invoke(Object proxy, 
                         Method method, 
                         Object[] args) throws Throwable {
        Object result = null; 
        try { 
            logger.log(Level.INFO, 
                         "method starts..." + method); 
            result = method.invoke(delegate, args); 
            logger.log(Level.INFO, 
                         "method ends..." + method); 
        } catch (Exception e){ 
            logger.log(Level.INFO, e.toString()); 
        } 
        return result; 
    } 
}

InvocationHandler的invoke()�Ҏ��會傳入被代理物�g的方法名�E�p��埯��參數實際上要埯��的方法交由method.invoke ()�Q�並在其前後加上�a�錄動作�Q�method.invoke()傛_��的物件是實際�Ҏ��埯��過後的回傳結果�?

Dynamic Proxy必須宣告介面�Q�實作該介面�Q�例如：

IHello.java

public interface IHello { 
    public void hello(String name); 
}

HelloSpeaker.java

public class HelloSpeaker implements IHello { 
    public void hello(String name) { 
        System.out.println("Hello, " + name); 
    } 
}

java.lang.reflect.Proxy的newProxyInstance()依要代理的物件、介面與handler產生一個代理物�Ӟ��我們可以��用下面的�Ҏ��來執行程式：

LogHandler logHandler = new LogHandler();
IHello helloProxy = (IHello) logHandler.bind(
new HelloSpeaker());
helloProxy.hello("Justin");

LogHandler不在服務於特定物件與介面�Q�而HelloSpeaker也不用插入�Q何有關於�a�錄的動作，它不用意識到�a�錄動作的存在�?br>

张金�?/a> 2007-04-17 10:38 发表评论

Design Pattern: Facade 模式

Tue, 17 Apr 2007 02:38:00 GMT

考慮您要撰寫一個Web Mail�E�式�Q�您手上已經有一些已�E�開發好的元�Ӟ��Component�Q�，像是開發Web Mail所需要的SMTP處理��、允�a׃��傳附檔的FileUpload��，以及Web安全盔R��的API、其它相關的Package�{�等�?br>
當您拿到一些現成的元�g�Q�並打算在您的應用程式中使用它們的話，您不應該直接��這些元�g耦合��x��的應用程式上�Q�例如：

上面的作法會讓您的應用程式直接與多個元件耦合�Q�這種作法不但與元件的依賴度高�Q�日後要修改應用�E�式本��n�Q�或是更換掉依賴的元仉��有困難�?br>
您應該定��一個Facade介面�Q�在當中定義好商務邏輯，例如寄送附件檔案的�Ҏ��Q�method�Q�，然後在一個實��N��中，�i�合您手邊的元�g�Q��光��成您所希望的商務行為，例如�Q?br>

如上圖所�C�的�Q�您的應用程式本�w�將不直接依賴於您的元�g�Q�而是依賴一個介面，當您惌��更改某個商務行為的實作時，只要修改實現的類��可以了�Q�應用程式本�w�不用作��M��修改�?br>
Facade模式的結構如下：
screen.width-250) this.width=screen.width-250">

Facade模式��p��了各個元件之間的合作行為�Q�以及元件本�w�的操作與設定細��Q�固而必失去了一些直接操作元件的方便性，所以對於喜歡追求與操作細節的程式設�a��h員而言�Q�不會很喜歡透過Facade來操作背後的元�g�Q�所以您的Facade介面�a�計�Q�通常要在元�g依賴性及元�g的支接操作性之間作個��^衡�?br>

张金�?/a> 2007-04-17 10:38 发表评论

Tue, 17 Apr 2007 02:37:00 GMT

�?Gof 的書中對Proxy模式的目的��定為�Q�為其它的物件提供一�E�代理，以控制對這個物件的�a�問。由這句話所延��Z��的意思是�Q�根據您的目的不同，您的代理物�g��負有不同的責�Q�Q�因為產生多�E�不同的代理情況�?br>
�Ҏ��不同的代理目的，而有不同的代理情況，在Gof中所舉的一個例子是Virtual Proxy�Q�當中舉一個文檔中內嵌圖片的例子，假設您的圖片是在文檔分頁的後面，一開始您並不用直接載入圖片�Q�而��用一個虛代理物�g�Q�代替圖片被載入�Q�以求開啟一個文檔的時候，速度能夠加快。當您捲動文檔至該顯�C�圖片的頁數時，這時再載入圖片�?br>

如上圖所�C�，當文檔被開啟時，ImageProxy物�g代理Image物�g被載入，在還沒捲動至圖片��示處時�Q�也��是還沒有調�?ImageProxy的draw()時，圖片並不會被載入�Q�因而可以加速文檔的開啟與節省記憉��的��用；如果需要顯�C�圖片了�Q�ImageProxy�?draw()會被調用�Q�而這時才真正創建Image物�g�Q�以從硬��中載入圖片�?br>
Proxy模式�?UML �i�構圖如下所�C�：

在調用RealSubject的request()之前�Q�Proxy物�g也許會有一些預先處理的操作�Q�就假設我們組�J�為preOperation()�?postOperation()好了�Q�當客戶��Proxy發出request()請求後，一個可能的時序圖如下所�C�：

您的preOperation()與postOperation()正決定了Proxy模式使用��g��E�情況，例如一個Remote Proxy的情況，可以��Z��個遠端真實物件提供一個局部代表；Protection Proxy控制��物件的�a�問�Q�您可以使用它來作不同級別、權限的存取控制�Q�Cache Proxy��Z��個物件提供臨時的儲存�Q��得許多客戶端都能直接存取它，而不用對真實物�g直接要求�Q�只有在必要的時候更新這個臨時物�Ӟ��或是讓客戶直接存取真實物件�?

张金�?/a> 2007-04-17 10:37 发表评论