軟件工程第13章軟件模式1模式很多系統的解決方案都比較類似解決方案的共同點是什么？區別在何處？用到哪些特殊的方法？如何制定一個特殊的方法？2Architecture,DesignandImplementation表示軟件系統的基本結構化組織圖式。提供一個用于細化軟件系統的子系統或組件，或它們之間關系的圖式。3模式類別體系結構模式可作為具體軟件體系結構的模版。它們規定一個應用的系統范圍的結構特性，以及對其子系統的體系結構施加的影響。體系結構模式的選擇是開發一個軟件系統時的基本設計決策。4模式類別設計模式軟件體系結構的子系統，以及它們之間的關系。通常由幾個更小的體系結構單元構成。中等規模的模式。規模上比體系結構模式小，但又獨立于特定編程語言。設計模式的應用對軟件系統的基礎結構沒有影響，但可能對子系統的體系結構有所影響。提供分解更復雜的服務或組件的結構，以及它們之間的合作。5模式類別慣用法處理特定設計問題的實現代表最低層模式，關注設計和實現方面針對具體語言，捕獲現有的編程經驗6Patterncharacteristics

一個模式關注一個在特定設計環境中出現的設計問題，并為它提供一個解決方案。各種模式用文檔記錄下現存的經過充分考驗的設計經驗。模式為設計原則提供一種公共的詞匯和理解。模式是為軟件體系結構建立文檔的一種手段。模式支持用已定義的屬性來構造軟件。7Patternschema語境：問題出現的場景問題：在那個語境中出現的再現問題解決方案必須滿足的需求必須考慮的約束解決方案必須具有的特性解決方案：已被證實的問題的解決方案特定的結構：組件和關系的結構運行期的行為8Patternschema模式的圖式：9內容摘要架構模式設計模式物理體系結構建模10內容摘要架構模式設計模式物理體系結構建模11ArchitecturePatterns一個軟件體系結構的模式描述了一個出現在特定設計語境中的特殊的再現設計問題，并為它的解決方案提供了一個經過充分驗證的通用圖式。一組預先確定的子系統和他們的職責子系統間的相互關聯的規則例如：Model-View-Controller模式12Pattern:Layers13Pattern:Layers

層體系結構模式有助于構建這樣的應用：它能被分解成子任務組，其中每個子任務組處于一個特定的抽象層次上。下層為上層提供服務上層利用下層提供的服務完成自身的任務通過同步程序調用來完成請求的服務14Pattern:Layers

ISOOpenSystemsInterconnect7-layermodel15Patternschema一個獨立層的描述16Pattern:Layers舉例：虛擬機e.g.JVM舉例：

APIse.g.Cstandardlibrary,builtonUnixsystemcalls舉例：信息系統應用層——數據庫表示層——應用邏輯層——領域層——數據庫17Pattern:Layers舉例：WindowsNT系統服務：子系統和NT執行程序之間的接口層資源管理器層：包含對象管理器、安全引用監視器、過程管理器、I/O管理器、虛擬存儲管理器和局部過程調用等模塊。內核：它關心一些基本功能，如中斷和意外處理、多處理器同步、線程調度和現程分配。硬件抽象層(HAL)：隱藏了不同處理器系列機器之間的硬件差異。硬件18Three-LayeredEnterpriseApplication19Pattern:Layers優點：層的重用標準化支持局部性依賴可替換性不足更改行為的重疊降低效率不必要的工作難以認可層的正確粒度20Pattern:Model-View-Controller21Pattern:Model-View-Controller將一個交互式應用程序分為三個組件。模型(Model)：核心功能和數據視圖(Views)：向用戶顯示信息控制器(Controllers)：處理用戶輸入視圖和控制器共同構成了用戶接口變更-傳播機制確保了用戶接口和模型之間的一致性22Pattern:Model-View-Controller23Pattern:Model-View-Controller24Pattern:Model-View-Controller相同的信息在不同的窗口有不同的表示支持不同的“樣式和感覺”標準模型獨立于表示布告形式連接觀察者設計模式舉例：SmalltalkASP.NET.aspx：視圖.VB,.C#：控制25Pattern:Client-Server26Pattern:Client-Server服務器端為客戶端提供服務客戶端從服務器端請求服務服務器一直保持監聽請求的狀態舉例：遠程數據庫連接遠程文件系統多層信息系統Web應用27Pattern:Master-Slave28Pattern:Master-Slave支持容錯性、并行計算以及計算準確性。主控組件將工作分配給相同的從屬組件，并從從屬組件返回的結果中計算最終的結果。舉例：嵌入式系統大規模并行計算容錯系統29Pattern:Master-Slave30Pattern:Master-Slave31Pattern:Master-Slave主控模塊故障，整個系統故障主控模塊將任務劃分為幾個同等的子任務從屬之間相互獨立從屬之間并行工作問題是可以分解的應用領域：容錯并行計算計算準確性32Pattern:Master-Slave優點：可互換性和可擴充性事務分離效率不足：可行性對機器依賴性難以實現可移植性33Pattern:Pipe-Filter34Pattern:Pipe-Filter管道和過濾器體系結構模式，為處理數據流的系統提供了一種結構每個處理步驟封裝在一個過濾器組件中數據通過相鄰過濾器之間的管道傳輸管道處理緩沖和同步重組過濾器可以建立相關系統族舉例：編譯器Unix內核命令35Pattern:Pipe-Filter36Pattern:Pipe-Filter37Pattern:Pipe-Filter優點：通過過濾器交換增加了靈活性通過重組增加了靈活性過濾器組件的重用并行處理提高效率不足：共享狀態信息或者昂貴或者不靈活并行處理獲得的效率往往只一種假象數據轉換額外開銷錯誤處理38Pattern:Broker39Pattern:Broker代理者結構模式可以用于構建帶有隔離組件的分布式軟件系統，該軟件通過遠程服務調用進行交互。代理者組件負責協調通信轉發請求、傳送結果和異常服務器將他們的服務（屬性和操作）發布給一個代理客戶端通過一個代理請求服務器處理代理將請求發送給一個合適的服務器處理40Pattern:Broker允許動態改變、添加、刪除和重新發布對于開發者來說，代理是透明的請求需要有標準的表示法當兩個代理者互操作時，實現細節可通過網橋來隱藏舉例：公共對象請求代理體系結構（CORBA），處理異構系統上分布式對象的面向對象技術Webservices41Pattern:Broker42Pattern:Peer-2-Peer43Pattern:Peer-2-Peer對稱的客戶機-服務器模式客戶機向服務器請求服務服務器通知客戶機特定的事件任何一個節點都可以扮演客戶機或者服務器的角色可以動態的交換角色舉例：多用戶應用P2P技術44Pattern:Event-Bus45Pattern:Event-Bus事件源將消息發布到總線上的特殊通道上事件監聽者訂閱通道上的消息監聽者監聽有效消息消息是異步的通路可以是固定的46Pattern:Blackboard47Pattern:Blackboard黑板體系結構模式對于無確定性求解策略的問題比較有用。黑板模式中，有幾個專用子系統收集其知識，以建立一個可能的部分解或近似解。舉例：語音識別所有組件共享數據存儲（黑板）組件生成新的數據更新到黑板組件監視黑板上的數據利用匹配模式尋找特定的數據48Pattern:Blackboard49Pattern:Blackboard50Pattern:Blackboard優點：對可更改性和可維護性的支持可重用的知識源支持容錯性和健壯性不足：測試困難不能保證有好的求解方案難以建立一個好的控制策略低效昂貴的開發工作缺少對并行機制的支持51內容摘要架構模式設計模式物理體系結構建模5223種設計模式簡介Abstractfactory(抽象工廠)提供一個創建一系列相關或相互依賴對象的接口，而無需制定它們具體的類。Adapter(適配器)將一個類的接口轉換成客戶希望的另一個接口。它使得原本由于接口不兼容而不能在一起工作的那些類可以在一起工作。Bridge(橋接)將抽象部分與它的實現部分分離，使它們都可以獨立的變化。5323種設計模式簡介Builder(生成器)將一個復雜對象的構建與它的表示分離，使得同樣的構建過程可以創建不同的表示。ChainofResponsibility(職責鏈)為解除請求的發送者和接受者之間的耦合，而使多個對象都有機會處理這個請求。將這些對象連成一條鏈，并沿著這個鏈傳遞該請求，直到有一個對象處理它。Command(命令)將一個請求封裝成一個對象，從而使你可用不同的請求對客戶進行參數化；對請求排隊或記錄請求日志，以及支持可取消的操作。5423種設計模式簡介Composite(組成)將對象組合成樹型結構以表示“部分-整體”的層次結構。它使得客戶對單個對象和復合對象的使用具有一致性。Decorator(裝飾)動態的給一個對象添加一些額外的職責。就擴展功能而言，該模式比生成子類的方式更為靈活。Facade(外觀)為子系統中的一組接口提供一個已知的界面，該模式定義了一個高層接口，這個接口使得這一子系統更加容易使用。5523種設計模式簡介FactoryMethod(工廠方法)定義一個用于創建對象的接口，讓子類決定將哪一個類實例化。它使得一個類的實例化延遲到其子類。Flyweight(享元)運用共享技術有效地支持大量細粒度的對象。Interpreter(解釋器)給定一個語言，定義它的文法的一種表示，并定義一個解釋器，該解釋器使用該表示來解釋語言中的句子。5623種設計模式簡介Iterator(迭代器)提供一種方法順序訪問一個聚合對象中的各個元素，而又不需暴露該對象的內部表示。Mediator(中介者)用一個中介對象來封裝一些列的對象交互。中介者使各對象不需要顯示地相互引用，從而使其耦合松散，而且可以獨立地改變它們之間的交互。Memento(備忘錄)在不破壞封裝性的前提下，捕獲一個對象的內部狀態，并在該對象之外保存這個狀態。這樣以后就可將該對象恢復到保存的狀態。5723種設計模式簡介Observer(觀察者)定義對象間的一種一對多的依賴關系，以便當一個對象的狀態發生改變時，所有依賴于它的對象都得到通知并自動刷新。Prototype(原型)用原型實例制定創建對象的種類，并通過拷貝這個原型來創建新的對象。Proxy(代理)為其他對象提供一個代理以控制對這個對象的訪問。5823種設計模式簡介Singleton(單件)保證一個類僅有一個實例，并提供一個訪問它的全局訪問點。State(狀態)允許一個對象在其內部狀態改變時改變它的行為。對象看起來似乎修改了他所屬的類。Strategy(策略)定義一系列算法，把它們一個個封裝起來，并且使它們可相互替換。本模式使得算法的變化可獨立于使用它的客戶。5923種設計模式簡介TemplateMethod(模版方法)定義一個操作中的算法的骨架，而將一些步驟延遲到子類中。該模式使得子類可以不改變一個算法的結構即可重定義該算法的某些特定步驟。Visitor(訪問者)表示一個作用于某對象結構中的各元素的操作。它使你可以在不改變各元素的類的前提下定義作用于這些元素的新操作。60模式分類目的創建型結構型行為型范圍類FactoryMethodAdapter(類)InterpreterTemplateMethod對象AbstractFactoryBuilderPrototypeSingletonAdapter(對象)BridgeCompositeDecoratorFa?adeFlyweightProxyChainofResponsibilityCommandIteratorMediatorMementoObserverStateStrategyVisitor61設計模式優點面向接口編程創建型模式確保系統是采用針對接口的方式書寫的，而不是針對實現而書寫的。降低耦合性增加靈活性62設計模式創建型模式將系統使用哪些具體的類的信息封裝起來隱藏了這些類的實例是如何被創建和放在一起的63設計模式之Factory-工廠模式客戶類和工廠類分開。客戶任何時候需要某種產品，只需向工廠請求即可。客戶無須修改就可以接納新產品。缺點是當產品修改時，工廠類也要做相應的修改。64656667設計模式之Factory-工廠模式68FACTORYMETHOD-工廠方法69FACTORYMETHOD-工廠方法意圖定義一個用于創建對象的接口，讓子類決定實例化哪一個類。FactoryMethod使一個類的實例化延遲到其子類。

適用性：當一個類不知道它所必須創建的對象的類的時候；當一個類希望由它的子類來指定它所創建的對象的時候當類將創建對象的職責委托給多個幫助子類的某一個，并且你希望將哪一個幫助子類是代理者這一信息局部化的時候70FACTORYMETHOD-工廠方法結構參與者Product——定義工廠方法所創建的對象的接口ConcreteProduct——實現Product接口Creator——聲明工廠方法，該方法返回一個Product類型的對象。可以調用工廠方法以創建一個Product對象。ConcreteCreator——重定義工廠方法以返回一個ConcreteProduct實例71FACTORYMETHOD-工廠方法協作Creator依賴于它的子類來定義工廠方法，所以它返回一個適當的ConcreteProduct實例72publicabstractclassCarFactory{

publicabstractCarcreator();}publicclassVM1FactoryextendsFactory{ publicCarcreator(){

.........

returnnewCar

}}publicclassVM2FactoryextendsFactory{ publicCarcreator(){

......

returnnewCar

}}73AbstractFactory–抽象工廠意圖提供一個創建一系列相關或相互依賴對象的接口，而無需指定它們具體的類。74AbstractFactory–抽象工廠參與者AbstractFactory——聲明一個創建抽象產品對象的操作接口ConcreteFactory——實現創建具體產品對象的操作AbstractProduct——為一類產品對象聲明一個接口ConcreteProduct定義一個將被相應的具體工廠創建的產品對象實現AbstractProduct接口Client僅使用由AbstractFactory和AbstractProduct類聲明的接口協作通常在運行時刻創建一個ConcreteFactory類的實例。這一具體的工廠創建具有特定實現的產品對象。為創建不同的產品對象，客戶應適用不同的具體工廠。AbstractFactory將產品對象的創建延遲到它的ConcreteFactory子類。75publicabstractclassCarFactory{

publicabstractCarcreator();

publicabstractTruckcreator(Strings);}publicclassVM1FactoryextendsFactory{

publicCarcreator(){

.........

returnnewJetta

}

publicTruckcreator(Strings){

.........

returnnewBigBig

}}publicclassVM2extendsFactory{

publicCarcreator(){

......

returnnewPolo

}

publicTruckcreator(Strings){

......

returnnewLLL

}}76AbstractFactory–抽象工廠與FactoryMethod模式的比較FactoryMethod模式利用給Factory對象傳遞不同的參數，以返回具有相同基類或實現了同一接口的對象AbstractFactory模式先利用Factory模式返回Factory對象，再通過Factory對象返回不同的對象77Builder-建造模式將一個復雜對象的構建與它的表示分離，使得同樣的構建過程可以創建不同的表示。

建造模式可以強制實行一種分步驟進行的建造過程。78Builder-建造模式參與者：Builder——為創建一個Product對象的各個部件制定抽象接口。ConcreteBuilder實現Builder的接口以構造和裝配該產品的各個部件定義并明確它所創建的表示提供一個檢索產品的接口Derector——構造一個使用Builder接口的對象Product表示被構造的復雜對象包含定義組成部件的類79Builder-建造模式協作：客戶創建Director對象，并用它所想要的Builder對象進行配置一旦產品部件被生成，導向器就會通知生成器生成器處理導向器的請求，并將部件添加到該產品中客戶從生成器中檢索產品80publicinterfaceBuilder{

//創建部件A：比如汽車車輪

voidbuildPartA();

//創建部件B：比如方向盤

voidbuildPartB();

//創建部件C：比如發動機

voidbuildPartC();

//返回最終組裝產品成果（返回最后裝配好的汽車）

//成品的組裝過程不在這里進行，而是轉移到下面的Director中進行。

//從而實現過程與部件的解耦。

ProductgetResult();}publicclassDirector{

privateBuilderbuilder; publicDirector(Builderbuilder){

this.builder=builder;

}

//將partA,partB,partC最后組成復雜物件

//汽車的組裝過程

publicvoidconstruct(){

builder.buildPartA();

builder.buildPartB();

builder.buildPartC();

}}81PROTOTYPE-原型模式意圖用原型實例指定創建對象的種類，并且通過拷貝這些原型創建新的對象。其實是將product和factory功能合二為一了。缺點是每一個類都必須配備一個克隆方法。適用性：當一個系統應該獨立于它的產品創建、構成和表示時，要使用Prototype模式；以及當要實例化的類是在運行時刻指定時；或者為了避免創建一個與產品類層次平行的工廠類層次時；或者當一個類的實例只能由幾個不同狀態組合中的一種時。建立相應數目的原型并克隆它們可能比每次用合適的狀態手工實例化該類更方便一些。82PROTOTYPE-原型模式參與者Prototype——聲明一個克隆自身的接口。ConcretePrototype——實現一個克隆自身的操作。Client——讓一個原型克隆自身從而創建一個新的對象。協作客戶請求一個原型克隆自身83publicabstractclassAbstractSpoonimplementsCloneable

{

StringspoonName;

publicvoidsetSpoonName(String

spoonName){this.spoonName=spoonName;}

publicStringgetSpoonName(){returnthis.spoonName;}

publicObjectclone()

{

Objectobject=null;

try{

object=super.clone();

}catch(CloneNotSupportedExceptionexception){

System.err.println("AbstractSpoonisnotCloneable");

}

returnobject;

}

}

publicclassSoupSpoonextendsAbstractSpoon

{

publicSoupSpoon()

{

setSpoonName("SoupSpoon");

}

}publicclassSaladSpoonextendsAbstractSpoon

{

publicSaladSpoon()

{

setSpoonName("SaladSpoon");

}

}84設計模式之Singleton-單例模式意圖保證一個類僅有一個實例，并提供一個訪問它的全局訪問點。

類自身負責保存它的唯一實例。解決的主要是性能問題，而非耦合（變化）的問題。適用性當類只能由一個實例而且客戶可以從一個眾所周知的訪問點訪問它時當這個唯一實例應該是通過子類化可擴展的，并且客戶應該無需更改代碼就能使用一個擴展的實例時。85設計模式之Singleton-單例模式參與者Singleton定義一個Instance操作，允許客戶訪問它的唯一實例。可能負責創建它自己的唯一實例。協作客戶只能通過Singleton的Instance操作訪問一個Singleton實例。86publicclassSingleton{

privatestaticSingletoninstance=null;

publicstaticsynchronizedSingletongetInstance(){

//這個方法比上面有所改進，不用每次都進行生成對象，

//只是第一次使用時生成實例，提高了效率！

if(instance==null)

instance＝newSingleton();

returninstance;

}}

87創建型模式小結創建型模式規定了創建對象的方式。在必須決定實例化某個類時，使用這些模式。通常，由抽象超類封裝實例化類的細節，這些細節包括這些類確切是什么，以及如何及何時創建這些類。對客戶類來講，這些類的細節是隱藏的。客戶類只知道抽象類或抽象類實現的接口。客戶類通常并不知道具體類的確切類型。當系統演化依賴于對象的組合、聚集時，創建型模式帶來了更大的靈活性。88設計模式結構型模式如何組合類和對象以獲得更大的結構類模型采用繼承機制來組合接口或實現，如采用多重繼承方法將兩個以上的類組合成一個類對象模式不是對接口和實現進行組合，它描述了如何對一些對象進行組合，從而實現新功能的一些方法。在運行時刻改變對象組合關系，具有更大的靈活性。89Adapter-適配器把一個類的接口變換成客戶端所期待的另一種接口，從而使原本因接口原因不匹配而無法一起工作的兩個類能夠一起工作。適配類可以根據參數返還一個合適的實例給客戶端。90使用多重繼承對一個接口與另一個接口進行匹配91對象匹配器依賴于對象組合92Adapter-適配器參與者Target——定義Client使用的與特定另一相關的接口Client——與符合Target接口的對象協同Adaptee——定義一個已經存在的接口，這個接口需要適配Adapter——對Adaptee的接口與Target接口進行適配協作Client在Adapter實例上調用一些操作。接著適配器調用Adaptee的操作實現這個請求。93publicinterfaceIRoundPeg{

publicvoidinsertIntoHole(String

msg);}publicinterfaceISquarePeg{

publicvoidinsert(String

str);}publicclassPegAdapterimplementsIRoundPeg,ISquarePeg{

privateRoundPeg

roundPeg;

privateSquarePeg

squarePeg;

//構造方法

publicPegAdapter(RoundPeg

peg){this.roundPeg=peg;}//構造方法

publicPegAdapter(SquarePeg

peg){this.squarePeg=peg;}

publicvoidinsert(String

str){roundPeg.insertIntoHole(str);}

publicvoidinsertIntoHole(String

str){SquarePeg.insert(str);}}9495Bridge-橋梁模式將抽象部分與它的實現部分分離，使它們都可以獨立地變化。解決2個方面的變化問題：抽象與實現。即一個類中多個方向的變化問題。96Bridge-橋梁模式參與者Abstraction定義抽象類的接口維護一個指向Implementor類型對象的指針RefinedAbstraction——擴充由Abstraction定義的接口Implementor——定義實現類的接口，該接口不一定要與 Abstraction的接口完全一致。ConcreteImplementor——實現Implementor接口并定義它的具體 實現協作Abstraction將Client的請求轉發給它的Implementor對象97publicabstractclassCoffee

{

CoffeeImp

coffeeImp;

publicvoidsetCoffeeImp(){

this.CoffeeImp=CoffeeImpSingleton.getTheCoffeImp();

}

publicSodaImp

getCoffeeImp(){returnthis.CoffeeImp;}

publicabstractvoidpourCoffee();

}publicabstractclassCoffeeImp

{

publicabstractvoidpourCoffeeImp();

}//bridgepublicclassCoffeeImpSingleton

{privatestaticCoffeeImp

coffeeImp;

publicCoffeeImpSingleton(CoffeeImp

coffeeImpIn)

{this.coffeeImp=coffeeImpIn;}

publicstaticCoffeeImp

getTheCoffeeImp()

{

returncoffeeImp;

}

}

9899Bridge-橋梁模式100Composite-合成模式合成模式把部分與整體關系用樹結構表示。合成模式使得用戶對單個對象和組合對象的使用具有一致性。101102Composite-合成模式參與者Component為組合中的對象聲明接口在適當的情況下，實現所有類共有接口的缺省行為聲明一個接口用于訪問和管理Component的子組件（可選）在遞歸結構中定義一個接口，用于訪問一個父部件，并在合適的情況下實現它Leaf在組合中表示葉節點對象，葉節點沒有子節點在組合中定義圖元對象的行為Composite定義有子部件的那些部件的行為存儲子部件在Component接口中實現與子部件有關的操作Client通過Component接口操縱組合部件的對象103Composite-合成模式協作用戶使用Component類接口與組合結構中的對象進行交互。如果接收者是一個葉節點，則直接處理請求。如果接收者是Composite，它通常將請求發送給它的子部件，在轉發請求之前與/或之后，可能執行一些輔助操作。104publicabstractclassEquipment{

privateStringname;

//網絡價格

publicabstractdoublenetPrice();

//打折價格

publicabstractdoublediscountPrice();

//增加部件

publicboolean

add(Equipmentequipment){returnfalse;}

//刪除部件

publicboolean

remove(Equipmentequipment){returnfalse;}

//注意這里，提供一種用于訪問組合部件的方法。

publicIterator

iter(){returnnull;}

publicEquipment(finalStringname){=name;}}

publicclassDiskextendsEquipmentabstractclassCompositeEquipmentextendsEquipment105DECORATOR-裝飾模式意圖動態地給一個對象添加一些額外的職責。就增加功能來說，Decorator模式相比生成子類更為靈活。一個類可能有些額外的責任（除了主體業務操作），如加密、緩存、壓縮等，這些可能只是輔助主體業務的附著，并不嚴格按照維度變化。裝飾模式以對客戶端透明的方式擴展對象的功能，是繼承關系的一個替代方案，提供比繼承更多的靈活性。動態給一個對象增加功能，這些功能可以再動態的撤消。增加由一些基本功能的排列組合而產生的非常大量的功能。既繼承又組合，實際上是將Bridge中的抽象和實現合二為一了，是其特殊形式。

106參與者Component——定義一個對象接口，可以給這些對象動態地添加職責。ConcreteComponent——定義一個對象，可以給這個對象添加一些職責。Decorator——維持一個指向Component對象的指針，并定義一個與 Component接口一致的接口ConcreteDecorator——向組件添加職責。協作Decorator將請求轉發給它的Component對象，并有可能在轉發請求前后執行一些附加的動作107publicinterfaceWork{

publicvoidinsert();}publicclassSquarePegimplementsWork{

publicvoidinsert(){

System.out.println(“方形杵插入");

}}publicclassDecoratorimplementsWork{

privateWorkwork;

//額外增加的功能打包在List中

privateArrayListothers=newArrayList();

//在構造器中使用組合new方式，引入Work;

publicDecorator(Workwork){

this.work=work;

others.add(“挖坑");

others.add(“釘木板");

}

publicvoidinsert(){

newMethod();

}

//新方法中在insert之前增加其他方法,這里次序先后是用戶靈活指定的

publicvoidnewMethod(){

otherMethod();

work.insert();

}

publicvoidotherMethod(){

ListIterator

listIterator=others.listIterator();

while(listIterator.hasNext())

{

System.out.println(((String)(listIterator.next()))+“正在進行");

}

}}108Facade-門面模式外部與一個子系統的通信必須通過一個統一的門面對象進行。門面模式提供一個高層次的接口，使得子系統更易于使用。每一個子系統只有一個門面類，而且此門面類只有一個實例，也就是說它是一個單例模式。但整個系統可以有多個門面類。109Facade-門面模式參與者Facade知道哪些子系統類負責處理請求將客戶的請求代理給適當的子系統對象Subsystem實現子系統的功能處理由Facade對象指派的任務沒有Facade的任何相關信息；即沒有指向Facade的指針協作客戶程序通過發送給Facade的方式與子系統通訊，Facade將這些消息轉發給適當的子系統對象。盡管是子系統中有關對象在做實際工作，但Facade模式本身也必須將它的接口轉換成子系統的接口。使用Facade的客戶程序不需要直接訪問子系統對象。110publicclassDBCompare{ Stringsql=“SELECT*FROM<table> WHERE<columnname>=?”;

try{

Mysql

msql=newmysql(sql);

prep.setString(1,“<columnvalue>”);

rset=prep.executeQuery();

if(rset.next()){

System.out.println(rset.getString(“<columnname>”));

}

}catch(SExceptione){

e.printStackTrace();

}finally{

mysql.close();

mysql=null;

}

}111FLYWEIGHT-享元模式享元模式以共享的方式高效的支持大量的細粒度對象。采用類似于Hash表的方式，共享的思想。客戶端不可以直接創建被共享的對象，而應當使用一個工廠對象負責創建被共享的對象。享元模式大幅度的降低內存中對象的數量，主要解決OO性能問題。112113FLYWEIGHT-享元模式參與者Flyweight描述一個接口，通過這個接口Flyweight可以接受并作用于外部狀態。ConcreteFlyweight實現Flyweight接口，并為內部狀態（如果有的話）增加存儲空間。UnsharedConcreteFlyweight并非所有的Flyweight子類都需要被共享。Flyweight接口使共享成為可能，但它并不強制共享。在Flyweight對象結構的某些層次，UnsharedConcreteFlyweight對象通常將ConcreteFlyweight對象作為子節點。FlyweightFactory創建并管理Flyweight對象確保合理地共享Flyweight。Client維持一個對Flyweight的引用計算或存儲一個（多個）Flyweight的外部狀態114FLYWEIGHT-享元模式協作Flywelght執行時所需的狀態必定是內部的或外部的。內部狀態存儲于ConcreteFlyweight對象之中；而外部對象則由Client對象存儲或計算。當用戶調用Flywelght對象的操作時，將該狀態傳遞給它。用戶不應直接對ConcreteFlyweight類進行實例話，而只能從FlywelghtFactory對象得到ConcreteFlyweight對象，這可以保證對它們適當地進行共享。115publicclassCD{

privateStringtitle;

privateintyear;

privateArtistartist;

publicStringgetTitle(){returntitle;}

publicint

getYear(){returnyear;}

publicArtistgetArtist(){returnartist;}

publicvoidsetTitle(Stringt){title=t;}

publicvoidsetYear(inty){year=y;}

publicvoidsetArtist(Artista){artist=a;}}publicclassArtist{

//內部狀態

privateStringname;

//notethatArtistisimmutable.

StringgetName(){returnname;}

Artist(Stringn){name=n;}}publicclassArtistFactory{

Hashtablepool=newHashtable();

ArtistgetArtist(Stringkey){

Artistresult; result=(Artist)pool.get(key); //產生新的Artist

if(result==null){

result=newArtist(key);

pool.put(key,result);

}

returnresult; }}116PROXY-代理模式代理模式給某一個對象提供一個代理對象，并由代理對象控制對源對象的引用。代理就是一個人或一個機構代表另一個人或者一個機構采取行動。代理對象可以在客戶和目標對象直接起到中介的作用。客戶端分辨不出代理主題對象與真實主題對象。代理模式可以并不知道真正的被代理對象，而僅僅持有一個被代理對象的接口，這時候代理對象不能夠創建被代理對象，被代理對象必須有系統的其他角色代為創建并傳入。117118PROXY-代理模式參與者Proxy保存一個引用使得代理可以訪問實體。提供一個與Subject的接口相同的接口，這樣代理就可以用來代替實體。控制對實體的存取，并可能負責創建和刪除它。Subject定義RealSubject和Proxy的公共接口，這樣就在任何使用RealSubject的地方都可以使用Proxy。RealSubject定義Proxy對代表的實體。協作代理根據其種類，在適當的時候向RealSubject轉發請求。119publicclassForumPermissionsimplementsCacheablepublicclassForumProxyimplementsForumpublicclassDbForumimplementsForum,Cacheable120設計模式行為模式算法和對象間職責的分配。不僅描述了對象或類的模式，還描述它們之間的通信模式。刻畫了在運行時難以跟蹤的復雜的控制流。121ChainofResponsibility–職責鏈很多對象由每一個對象對其下家的引用而接起來形成一條鏈。請求在這個鏈上傳遞，直到鏈上的某一個對象決定處理此請求。客戶并不知道鏈上的哪一個對象最終處理這個請求，系統可以在不影響客戶端的情況下動態的重新組織鏈和分配責任。處理者有兩個選擇：承擔責任或者把責任推給下家。一個請求可以最終不被任何接收端對象所接受。122123ChainofResponsibility–職責鏈參與者Handler定義一個處理請求的接口實現后繼鏈ConcreteHandle處理它所負責的請求可訪問它的后繼者如果可處理該請求，就處理之；否則將該請求轉發給它的后繼者。Client向鏈上的具體處理者對象提交請求協作當客戶提交一個請求時，請求沿鏈傳遞直至有一個ConcreteHandle對象負責處理它。124publicinterfaceHandler{

publicvoidhandleRequest(Requestrequest);}

publicclassRequest{

privateStringtype;

publicRequest(String

type){this.type=type;}

publicStringgetType(){returntype;}

publicvoidexecute(){

//request真正具體行為代碼

}}publicclassConcreteHandlerimplementsHandler{

privateHandlersuccessor;

publicConcreteHandler(Handlersuccessor){

this.successor=successor;

}

publicvoidhandleRequest(Requestrequest){

if(requestinstanceof

HelpRequest){

//這里是處理Help的具體代碼

}elseif(requestinstanceof

PrintRequst){

request.execute();

}else{

//傳送到下一個

successor.handle(request); } }}125COMMAND-命令模式

命令模式把一個請求或者操作封裝到一個對象中。命令模式把發出命令的責任和執行命令的責任分割開，委派給不同的對象。命令模式允許請求的一方和發送的一方獨立開來，使得請求的一方不必知道接收請求的一方的接口，更不必知道請求是怎么被接收，以及操作是否執行，何時被執行以及是怎么被執行的。系統支持命令的撤消。126127COMMAND-命令模式

參與者Command聲明執行操作的接口ConcreteCommand將一個接收者對象綁定與一個動作調用接收者相應的操作，以實現ExecuteClient創建一個具體命令對象并設定它的接收者Invoker要求該命令執行這個請求Receiver知道如何實施與執行一個請求相關的操作。任何類都可能作為一個接收者。128COMMAND-命令模式

協作Client創建一個ConcreteCommand對象并指定它的Receiver對象。某Invoker對象存儲該ConcreteCommand對象該Invoker通過調用Command對象的Execute操作來提交一個請求。若該命令是可撤銷的，ConcreteCommand就在執行Execute操作之前存儲當前狀態以用于取消命令。ConcreteCommand對象對調用它的Receiver的一些操作以執行該請求。129publicinterfaceCommand{

publicabstractvoidexecute();}publicclassproducer{

publicstaticListproduceRequests(){

Listqueue=newArrayList();

queue.add(newDomesticEngineer());

queue.add(newPolitician());

queue.add(newProgrammer());

returnqueue;

}}publicclassTestCommand{

publicstaticvoidmain(String[]args){

Listqueue=PduceRequests();

for(Iteratorit=queue.iterator();it.hasNext();) //取出List中的內容,其他特征不能確定，只能保證一個特征是100%正確，

//他們至少是界面Command的“兒子”。所以強制轉換類型為Command

((Command)it.next()).execute();

}}130INTERPRETER-解釋器模式給定一個語言后，解釋器模式可以定義出其文法的一種表示，并同時提供一個解釋器。客戶端可以使用這個解釋器來解釋這個語言中的句子。解釋器模式將描述怎樣在有了一個簡單的文法后，使用模式設計解釋這些語句。在解釋器模式里面提到的語言是指任何解釋器對象能夠解釋的任何組合。在解釋器模式中需要定義一個代表文法的命令類的等級結構，也就是一系列的組合規則。每一個命令對象都有一個解釋方法，代表對命令對象的解釋。命令對象的等級結構中的對象的任何排列組合都是一個語言。131132INTERPRETER-解釋器模式參與者AbstractExpression聲明一個抽象的解釋操作，這個接口為抽象語法樹種所有的節點所共享。TerminalExpression實現與文法中的終結符相關聯的解釋操作一個句子中的每個終結符需要該類的一個實例NonterminalExpression非終結符表達式Context包含解釋其之外的一些全局信息Client構建表示該文法定義的語言中一個特定的句子的抽象語法樹調用解釋操作133INTERPRETER-解釋器模式協作Client構建(或被給定)一個句子，它是NonterminalExpression和TerminalExpression的實例的一個抽象語法樹。然后初始化上下文并調用解釋操作。每一非終結符表達式節點定義相應子表達的解釋操作。而各終結符表達式的解釋操作構成了遞歸的基礎。每一節點的解釋操作用上下文來存儲和訪問解釋器的狀態。134ITERATOR-迭代子模式迭代子模式可以順序訪問一個聚集中的元素而不必暴露聚集的內部表象。多個對象聚在一起形成的總體稱之為聚集，聚集對象是能夠包容一組對象的容器對象。迭代子模式將迭代邏輯封裝到一個獨立的子對象中，從而與聚集本身隔開。迭代子模式簡化了聚集的界面。每一個聚集對象都可以有一個或一個以上的迭代子對象，每一個迭代子的迭代狀態可以是彼此獨立的。迭代算法可以獨立于聚集角色變化。135136ITERATOR-迭代子模式參與者Iterator——迭代器定義訪問和遍歷元素的接口。ConcreteIterator具體迭代器實現迭代器接口對該聚合遍歷時跟蹤當前位置Aggregate——聚合定義創建相應迭代器對象的接口ConcreteAggregate具體聚合實現創建相應迭代器的接口，該操作返回ConcreteIterator的一個適當的實例。協作ConcreteIterator跟蹤聚合中的當前對象，并能夠計算出待遍歷的后繼對象137遍歷Collection中內容publicclassTestCommand{

publicstaticvoidmain(String[]args){

Listqueue=PduceRequests();

for(Iteratorit=queue.iterator();it.hasNext();)

((Command)it.next()).execute();

}}138MEDIATOR-調停者模式調停者模式包裝了一系列對象相互作用的方式，使得這些對象不必相互明顯作用。從而使他們可以松散偶合。當某些對象之間的作用發生改變時，不會立即影響其他的一些對象之間的作用。保證這些作用可以彼此獨立的變化。調停者模式將多對多的相互作用轉化為一對多的相互作用。調停者模式將對象的行為和協作抽象化，把對象在小尺度的行為上與其他對象的相互作用分開處理。架構級模式，Fa?ade解決子系統間的問題，Mediator解決子系統內（對象間）復雜問題。139140MEDIATOR-調停者模式參與者Mediator中介者定義一個接口用于與各同事對象通信。ConcreteMediator具體中介者通過協調各同事對象實現協作行為了解并維護它的各個同事Colleagueclass每一個同事類都知道它的中介者對象每一個同事對象在需與其他的同時通信的時候，與它的中介者通信協作同事向一個中介對象發送和接收請求。中介者在各同事間適當地轉發請求以實現協作行為141publicinterfaceMediator{}publicclassConcreteMediatorimplementsMediator{

//假設當前有兩個成員

privateConcreteColleague1colleague1=newConcreteColleague1();

privateConcreteColleague2colleague2=newConcreteColleague2();

...}

publicclassColleague{

privateMediatormediator;

publicMediatorgetMediator(){

returnmediator; }

publicvoidsetMediator(Mediatormediator){

this.mediator=mediator; }}publicclassConcreteColleague1{}publicclassConcreteColleague2{}142MEMENTO-備忘錄模式備忘錄對象是一個用來存儲另外一個對象內部狀態的快照的對象。備忘錄模式的用意是在不破壞封裝的條件下，將一個對象的狀態捉住，并外部化，存儲起來，從而可以在將來合適的時候把這個對象還原到存儲起來的狀態。143144MEMENTO-備忘錄模式參與者Memento備忘錄存儲原發器對象的內部狀態。原發器根據需要決定備忘錄存儲原發器的哪些內部狀態。防止原發器以外的其他對象訪問備忘錄。Originator原發器創建一個備忘錄，用以記錄當前時刻它的內部狀態。使用備忘錄恢復內部狀態Caretaker負責保存好備忘錄不能對備忘錄的內容進行操作或檢查協作管理器向原發器請求一個備忘錄，保留一段時間后，將其送回給原發器。145publicclassOriginator{ privateintnumber; privateFilefile=null;

publicOriginator(){}

//創建一個Memento publicMementogetMemento(){

returnnewMemento(this); }

//恢復到原始值

publicvoidsetMemento(Mementom){

number=m.number;

file=m.file; }}privateclassMementoimplementsjava.io.Serializable{

privateintnumber;

privateFilefile=null;

publicMemento(Originatoro){

number=o.number;

file=o.file;

}}146OBSERVER-觀察者模式觀察者模式定義了一種一對多的依賴關系，讓多個觀察者對象同時監聽某一個主題對象。這個主題對象在狀態上發生變化時，會通知所有觀察者對象，使他們能夠自動更新自己。147148OBSERVER-觀察者模式參與者Subject（目標）目標知道它的觀察者。可以有任意多個觀察者觀察同一個目標。提供注冊和刪除觀察者對象的接口。Observer（觀察者）為那些在目標發生改變時需獲得通知的對象定義一個更新接口。ConcreteSubject

（具體目標）將有關狀態存入各ConcreteObserver對象當它的狀態發生改變時，向它的各個觀察者發出通知ConcreteObserver

（具體觀察者）維護一個指向ConcreteSubject

對象的引用存儲有關狀態，這些狀態應與目標的狀態保持一致實現Observer的更新接口以使自身狀態與目標的狀態保持一致149OBSERVER-觀察者模式協作當ConcreteSubject

發生任何可能導致其觀察者與其本省狀態不一致的改變時，它將通知它的各個觀察者在得到一個具體目標的改變通知后，ConcreteObserver對象可向目標對象查詢信息。ConcreteObserver使用這些信息以使它的狀態與目標對象的狀態一致。150publicclassproductextendsObservable{ privateStringname;

privatefloatprice;

publicStringgetName(){returnname;}

publicvoidsetName(){

=name;

//設置變化點

setChanged();

notifyObservers(name); }

}publicclassNameObserverimplementsObserver{

privateStringname=null;

publicvoidupdate(Observable

obj,Object

arg){

if(arg

instanceofString){

name=(String)arg;

//產品名稱改變值在name中

System.out.println("NameObserver:namechangetto"+name);

}

}}151STATE-狀態模式狀態模式允許一個對象在其內部狀態改變的時候改變行為。這個對象看上去象是改變了它的類一樣。狀態模式把所研究的對象的行為包裝在不同的狀態對象里，每一個狀態對象都屬于一個抽象狀態類的一個子類。狀態模式的意圖是讓一個對象在其內部狀態改變的時候，其行為也隨之改變。狀態模式需要對每一個系統可能取得的狀態創立一個狀態類的子類。當系統的狀態變化時，系統便改變所選的子類。管理類在不同狀態下的行為。152153STATE-狀態模式參與者Context定義客戶感興趣的接口維護一個ConcreteState子類的實例State定義一個接口以封裝與Context的一個特定狀態相關的行為ConcreteStatesubclasses每一子類實現一個與Context的一個狀態相關的行為154STATE-狀態模式協作Context將與狀態相關的請求委托給當前的ConcreteState

對象處理Context可將自身作為一個參數傳遞給處理該請求的狀態對象。這使得狀態對象在必要的時候可訪問Context。Context是客戶使用的主要接口Context或ConcreteState子類都可決定哪個狀態是另一個的后繼者，以及是在何種條件下進行狀態裝換。155publicclassBlueStateextendsState{ publicvoidhandlepush(Contextc){

//根據push方法“如果是blue狀態的切換到green”;

c.setState(new

GreenState());

}

publicvoidhandlepull(Contextc){

//根據pull方法“如果是blue狀態的切換到red”;

c.setState(new

RedState()); }

publicabstractvoidgetcolor(){return(Color.blue);}}publicclassContext{ privateSatestate=null;//將原來的Colorstate改成了新建的Statestate; //setState是用來改變state的狀態，使用setState實現狀態切換

pulicvoidsetState(Statestate){

this.state=state; } publicvoidpush(){

//狀態切換細節,本例是顏色變化,封裝在子類handlepush中,此處無需關心

state.handlepush(this);

//因為sample要使用state中的一個切換結果,使用getColor()

Samplesample=newSample(state.getColor());

sample.operate(); } publicvoidpull(){

state.handlepull(this);

Sample2sample2=newSample2(state.getColor());

sample2.operate();

}}156STRATEGY-策略模式策略模式針對一組算法，將每一個算法封裝到具有共同接口的獨立的類中，從而使得它們可以相互替換。策略模式使得算法可以在不影響到客戶端的情況下發生變化。策略模式把行為和環境分開。環境類負責維持和查詢行為類，各種算法在具體的策略類中提供。由于算法和環境獨立開來，算法的增減，修改都不會影響到環境和客戶端。與State較象，類中封裝