設計模式--策略模式，裝飾模式
阿新 • • 發佈：2019-01-10
堅持著客戶端程式碼是程式的入口，建構函式是類的入口為原則，對模式理解整理：
【策略模式】
策略模式（Strategy）是定義一系列演算法的方法，所有的演算法功能相同，但是實現不同。
如上圖，策略類strategy是演算法類基類，context（上下文）負責具體例項化演算法，使用上可以與簡單工廠相結合，將選擇成分（switch）注入該類中。
實現理解（從客戶端理解）：
1）例項化context類：Context context =new Context（new ConcreteStrategyA（）） 【裝飾模式】
裝飾模式（Decorator）將核心功能與裝飾功能分開，這樣就可以動態新增功能了！
人都是愛美的，把人看做最初的程式碼原型（元件 component），必然要穿衣服（decorator），不斷更換衣服樣式就是一種動態新增新功能的過程；一個程式中最初元件是功能程式碼的話，可以將新增背景，改變字型等操作看做是一種裝飾，讓操作更加簡便有效 實現過程（客戶端程式碼入手）： 1.例項化最初元件：提供最初母體。ConcreteComponent c=new ConcreteComponent 思考：提供的初級元件類中，裝飾者應該通過什麼方法來裝飾它？ 說明：將最初元件作為基類（可以為抽象類也可以是具體類），並提供虛擬展示（operation）方法，繼承子類通過重寫展示方法實現裝飾過程 2.例項化各元件 3.具體裝飾過程（迭代式裝飾），必須保證一個裝飾完成以後，第二個再裝飾不會影響先前的裝飾，而是以上一次的裝飾完成後作為基本元件進行的！ 思考：如何實現這樣的迭代裝飾？ 首先建立一個抽象的裝飾者（detector）類，繼承最初元件類，定義裝飾方法Decorate（），重寫展示方法Show（）（實現例項化的最初元件）；具體裝飾者（detector子類）重寫裝飾方法，實現過程中執行父類detector的show（）方法。 裝飾過程，是分先後順序的，基本元件裝飾一個detector後，又重新作為基本元件： 例如：sneakers.Decorate(Person) ;//為人穿上T恤，此時T恤又重新作為了基本元件 bigtrouser.Decorate(sneakers); //為上面的元件新增 缺點：1.裝飾模式程式碼實現較為複雜 2.必須注意順序問題，就好比一個人不能將內衣穿在外衣外面。解決的方法必須保證各個具體裝飾類之間 保持獨立。
【代理模式】
代理模式（Proxy），提供了一種通過代理來控制訪問物件的許可權。
實現過程：
1.定義基類，提供抽象要求方法request（）
2.真正的操作類繼承基類，重寫實現要求方法request（）
3.定義代理類繼承基類，重寫要求類，通過呼叫真實的request（）方法來最終實現
對代理的遠端，虛擬，安全和智慧指引方面的應用理解不是很深刻，單從代理這個詞義上理解，真實的操作通過代理去完成，對真實操作類可以起到隱藏和保護作用。