a)結構：

注：1)使多個物件都有機會處理請求，從而避免請求的傳送者和接收者之間耦合關係。將這些物件連成一條鏈，並沿著這條鏈傳遞該請求，直到有一個物件處理她為止。

b)優點：

i.降低耦合程度。每個物件僅需知道如何將請求往後轉發。（每個物件只需保留一個後繼的引用）

ii.在職責分發方面提供了額外的靈活性，可以在執行期間對鏈和職責進行修改。（通過修改後繼引用，動態調整鏈）

iii.當沒有一個物件能處理某個請求時，則最後一個物件丟棄該請求。（提供對請求的預設處理）

i.有多個物件可以處理一個請求時，哪個物件處理該請求，在執行時刻自動確定。

ii.你想在不明確指定接收者的情況下，向多個物件中的一個提交一個請求。

iii.

可處理一個請求的物件集合應被動態指定。

public abstract class Handler{

protected Handler successor;

public abstract void handleRequest();

}

public class HandlerA extends Handler{

public void handleRequest(){

if(can handle){

dosomething;

}else{

successor.handleRequest();

}

}

}

public class HandlerB extends Handler{

public void handleRequest(){

if(can handle){

doanotherthing;

}else{

successor.handleRequest();

}

}

}

e)小結：

i.要自己維護後繼者鏈。

ii.對於請求，可以用硬編碼表示，或者把請求封裝起來。

iii.幫助系統就是一個Chain of Responsibility的一個應用。

a)結構：

注：1)將一個請求封裝為一個物件，從而使你可用不同的請求對客戶進行引數化，對請求排隊或記錄請求日誌，以及支援可撤銷的操作。

b)優點：

i.把請求的處理封裝成一個特定的類，而不是通過一串if-else語句進行判定和指派。（JDK1.2中的事件模型是通過if-else實現，從J2SDK開始，事件模型是採用Command

模式的形式）

ii.可記錄請求序列，實現undo操作。（由於是在Invoker觸發事件，所以，可以在Invoker處對所發生過的事件進行記錄。或者通過提供一個全域性的事件日誌，每當Command執行其execute()方法時，都先在該日誌中進行填寫，實現請求佇列的記錄）

i.在不同的時刻指定，排列和執行請求。一個Commmand物件可以有一個與初始請求無關的生存期。如果一個請求的接收者可用一種與地址空間無關的方式表達，那麼就可將負責該請求的命令物件傳送給另一個不同的程序，並在那兒實現該請求。

ii.支援取消操作。（在Command內部，在execute方法的開始部分，進行狀態的記錄）

iii.支援修改日誌，這樣當系統崩潰時，這些修改可以被重做一遍。（因為記錄了請求佇列，所以可以進行重做）

iv.用構建在原語操作上的高層操作構造一個系統，這樣一種結構在支援事務的資訊系統中很常見。一個事務封裝了對資料的一組變動，Commmand模式提供了對事務進行建模的方法。Commmand有一個公共的介面，使得你可以用一種方式呼叫所有的事務。同時，使用該模式也易於新增新事務以擴充套件系統。

public class Invoker{

private Command[] commands;

public void onEvent(Event e){

if(e){

commands[i].execute();

}

}

}

public interface Command{

public void execute();

}

public class Receiver{

public void action(){}

}

public class CommandA implements Command{

private Receiver rec;

public void execute(){

rec.action();

}

}

e)小結：

i.Command模式可能導致生成很多小型的類。（可採用內部類解決）

ii.Java事件模型是Command模式的一個應用，其中的ActionListener相當於上述中的Receiver。

a)結構：

     注：1)提供一種方法順序訪問一個聚合物件中各個元素，而又不需要暴露該物件的內部表示。

b)優點：

i.在不需要暴露集合的結構的情況下，提供一種遍歷集合的方法。（由於是由集合負責建立Iterator，所以，只有Iterator知道集合的內部結構，而這個集合的結構對使用者是透明的）

i.訪問一個集合物件的內容，而無需暴露她的內部表示。

ii.支援對聚合物件的各種遍歷。

iii.為遍歷不同的聚合結構提供一個統一的介面。（所有的操作都定義在Iterator中）

public interface Aggregate{

public Iterator createIterator();

public int size();

public Node getNode(int index);

}

public interface Iterator{

public void first();

public void next();

public boolean isDone();

public Node current();

}

public class AggregateA implements Aggregate{

public Iterator createIterator(){

return new IteratorA(this);

}

}

public class IteratorA implements Iterator{

private Aggregate agg;

private int current;

private int size;

public void first(){

current = 0;

}

public void last(){

current = size - 1;

}

public void isDone(){

if(current == size)

return true;

else

return false;

}

public Node current(){

return agg.getNode(current);

}

}

e)小結：

i.誰控制該遍歷。一般有兩種方法。一是由客戶程式負責，另一種是由遍歷器負責。前一種方式比較靈活，但是程式碼重用的機率小，且耦合度大。後一種靈活性雖然不如前一種，但他可以方便的重用，優化，而且降低了客戶程式與集合間的耦合度。

ii.誰定義遍歷演算法。一般有兩種選擇。一是由集合自身定義遍歷演算法，然後集合把狀態儲存到遍歷器中，另一種是由遍歷器負責。前一種方法，便於儲存集合的私有資訊，不向遍歷器暴露。後一種方法，比較靈活，而且相同的遍歷演算法可以在不同的集合上重用。

iii.處理同步操作。當一個遍歷器在遍歷集合時，如果對集合進行了增刪操作，可能會導致重複訪問，或者少訪問了某個集合的元素，所以，需要提供一種手段來保證不發生以上情況。

iv.空遍歷器。當對Composite物件進行遞迴遍歷時。通過在葉子節點提供一個空遍歷器（isDone方法總是返回true），即可完成對樹形集合的遍歷訪問。

v.Java的Util包中的Iterator是對該模式的一個應用。

a)結構：

注：1)用一個物件來封裝一系列的物件互動。Mediator使各物件不需要顯式地相互引用，從而使其耦合鬆散，而且可以獨立地改變他們之間的互動。

b)優點：

i.降低了物件之間的耦合，將物件的行為區域性化在物件內部。（所有Colleague的通訊都集中到Mediator當中）

ii.通過修改Mediator的程式碼，可以很容易改變物件間的互動。

iii.可以很容易的在系統中增加新的Colleague，而不需要改變已有的程式碼。（Colleague只與Mediator通訊，他們之間互相不知道）

iv.Mediator解決了Command物件在執行程式碼時需要過多的瞭解其他物件的細節的問題。

i.一組物件以定義良好，但是複雜的方式進行通訊，產生的相互依賴關係結構很亂且難以維護。（Mediator用於解耦物件間的通訊）

ii.一個物件引用其他很多物件，並且直接與這些物件通訊，導致難以複用該物件。

iii.想定製一個分佈在多個類中的行為，而又不想生成太多的子類。

public interface Mediator{}

public class MediatorA implements Mediator{

private Colleague a;

private Colleague b;

public Mediator(){

a = new ColleagueA(this);

b = new ColleagueB(this);

}

public void doSomething(Colleague c){

b.doAnotherthing();

}

}

public abstract class Colleague{

protected Mediator m;

public Colleague(Mediator m){

this.m = m;

}

}

public class ColleagueA extends Colleague{

public ColleagueA(Mediator m){

super(m);

}

public void doSomething(){

m.doSomething(this);

}

}

         public class ColleagueB extends Colleague{

         public ColleagueB(Mediator m){

         super(m);

         }

         public void doAnotherthing(){

         …

         }

         }

e)小結：

i.Mediator模式可以減少子類生成。她把各Colleague中負責通訊的部分集中到一起，改變這些行為只需生成Mediator的子類即可，這樣各Colleague類可被重用。

ii.她將各Colleague子類進行解耦。

iii.她簡化了物件協議。從原來可能的n-n改成1-n.

iv.她對物件間的協作進行了抽象。

v.她使控制集中化。

vi.Facade模式也是對系統進行抽象，從而提供一個方便的介面，但是Facade模式的通訊是單向的，而Mediator是雙向的。

vii.自動機模型可以考慮採用Mediator模式來實現。

a)結構：

注：1)定義物件之間的一種一對多的依賴關係，當一個物件的狀態發生改變時，所有依賴於他的物件都得到通知，並被自動更新。

b)優點：

i.定義了一個抽象的物件間通訊框架。

i.當一個抽象模型有兩個方面，其中一個方面依賴於另一方面，將這兩者封裝在獨立的物件中以使他們可以各自獨立地改變和複用。（這方面類似於Builder模式和Bridge模式。Builder模式用於物件生成，Bridge模式用於抽象出通用介面，Observer模式用於對狀態改變進行通知）

ii.當對一個物件地改變需要同時改變其他物件，而不知道具體有多少物件有待改變。（這裡與Chain of Responsibility相似）

iii.當一個物件必須通知其他物件，而她又不能假定其他物件是誰，換言之，你不希望這些物件是緊密耦合的。（兩者之間的唯一關係，就是Observer必須實現update()方法）

public class Subject{

private Vector observers;

public void addObserver(Observer observer){

observers.add(observer);

}

public void removeObserver(Observer observer){

observers.remove(observer);

}

public void notify(){

for(Observer o:observers){

o.update(this);

}

}

}

public class SubjectA extends Subject{

private int state;

public void stateChanged(){

super.notify();

}

}

public interface Observer{

public void update(Subject sub);

}

public class ObserverA implements Observer{

public void update(Subject sub){

doSomething;

}

}

e)小結：

i.目標和觀察者之間的抽象耦合。目標只需要知道所有的觀察者都實現了update()方法。

ii.支援廣播通訊。目標與觀察者之間是1-n的關係。

iii.在Java中，由於Observerable是類，而Java不支援多繼承，因此，當一個類如果她已繼承了某個類，而又需要當一個Observerable時，可以使用一個內部類，讓該內部類繼承Observerable類。

a)結構：

     注：1)允許一個物件在其內部狀態改變時改變她的行為，物件看起來似乎修改了她的類。

2)Context通過替換她的state，達到修改其行為的目的。

b)優點：

i.把狀態資訊區域性化到一個單獨的類當中。（所有的State類）

ii.她把狀態變換外部化。（如果僅以一些內部資料值來定義當前狀態時，狀態改變就僅表示為一些變數賦值。但是，為不同的狀態引入獨立的物件，可以使得變換更加明確）

iii.狀態物件可以共享。（如果State物件沒有例項變數，則該State物件可以共享，他們避讓是沒有內部狀態，只有行為的輕量級物件）

i.一個物件的行為取決於她的狀態，並且她必須在執行時刻根據狀態改變她的行為。（類似於自動機模型，把行為與狀態繫結到一起）

ii.一個操作中含有龐大的條件語句，且這些分支依賴於該物件的狀態。這個狀態通常用一個或多個列舉常量表示。通常有多個操作包含這一相同的條件結構。State模式將每一個條件分支放入一個獨立的類中。這使得你可以根據物件自身的情況將物件的狀態作為一個物件，這一物件可以不依賴於其他物件而獨立化。

public class Context{

private State state;

public void request(){

if(conditionA){

state = new StateA();

}else if(conditionB){

state = new StateB();

}

state.handle();

}

}

public interface State{

public void handle();

}

public class StateA implements State{

public void handle(){…}

}

     public class StateB implements State{

     public void handle(){…}

     }

e)小結：

i.誰定義狀態轉換：如果轉換規則是固定的，則可以由Context來定義。另一種方法是由每個State負責記錄她的後繼State，當發生轉換時，由State設定Context的狀態。

a)結構：

注：1)定義一系列的演算法，把他們一個個封裝起來，並且使他們可相互替換，本模式使得演算法可獨立於使用他們的客戶而變化。

2)Strategy模式與State模式非常相似，但是Strategy模式的目標是實現演算法的替換，演算法之間不存在順序關係，State模式的目標是實現狀態的轉換，狀態之間有一定的先後次序。

b)優點：

i.使用者可以動態的選擇策略。（替換strategy例項）

ii.可以新增新的演算法而不需修改客戶程式碼。（所有的Strategy子類都有相同的介面）

i.許多相關的類僅僅是行為有異，“策略”提供了一種用多個行為中的一個來配置一個類的行為。

ii.需要使用一個演算法的不同變體。

iii.演算法使用客戶不應該知道的資料。可使用策略模式以避免暴露覆雜的，與演算法相關的資料結構。

iv.一個類定義了多種行為，並且這些行為在這個類的操作中以多個條件語句的形式出現。將相關的條件移入他們各自的Strategy類中以代替這些語句。

public class Context{

private Strategy strategy;

public void selectStrategy(String name){

if(name == conditionA)

strategy = new StrategyA();

else

strategy = new StrategyB();

相關推薦