1. 程式人生 > >Java面向物件設計模式(十三)——策略模式(strategy)

Java面向物件設計模式(十三)——策略模式(strategy)

策略模式(strategy)

策略模式定義了一系列演算法,並將每個演算法封裝起來,使他們可以相互替換,且演算法的變化不會影響到使用演算法的客戶。

        一種方法是 需要設計一個介面,為一系列實現類提供統一的方法,多個實現類實現該介面,設計一個抽象類(可有可無,屬於輔助類),提供輔助函式,關係圖如下:


圖中ICalculator提供同意的方法,AbstractCalculator是輔助類,提供輔助方法,接下來,依次實現下每個類:

首先統一介面:

  1. publicinterface ICalculator {  
  2.     publicint calculate(String exp);  
  3. }  

輔助類:

  1. publicabstractclass AbstractCalculator {  
  2.     publicint[] split(String exp,String opt){  
  3.         String array[] = exp.split(opt);  
  4.         int arrayInt[] = newint[2];  
  5.         arrayInt[0] = Integer.parseInt(array[0]);  
  6.         arrayInt[1] = Integer.parseInt(array[1]);  
  7.         return
     arrayInt;  
  8.     }  
  9. }  

三個實現類:

  1. publicclass Plus extends AbstractCalculator implements ICalculator {  
  2.     @Override
  3.     publicint calculate(String exp) {  
  4.         int arrayInt[] = split(exp,"\\+");  
  5.         return arrayInt[0]+arrayInt[1];  
  6.     }  
  7. }  
  1. publicclass Minus extends AbstractCalculator 
    implements ICalculator {  
  2.     @Override
  3.     publicint calculate(String exp) {  
  4.         int arrayInt[] = split(exp,"-");  
  5.         return arrayInt[0]-arrayInt[1];  
  6.     }  
  7. }  
  1. publicclass Multiply extends AbstractCalculator implements ICalculator {  
  2.     @Override
  3.     publicint calculate(String exp) {  
  4.         int arrayInt[] = split(exp,"\\*");  
  5.         return arrayInt[0]*arrayInt[1];  
  6.     }  
  7. }  

簡單的測試類:

  1. publicclass StrategyTest {  
  2.     publicstaticvoid main(String[] args) {  
  3.         String exp = "2+8";  
  4.         ICalculator cal = new Plus();  
  5.         int result = cal.calculate(exp);  
  6.         System.out.println(result);  
  7.     }  
  8. }  

輸出:10

另一種方法是 定義一個抽象策略類,定義所有支援的演算法的公共介面;具體策略類封裝所有的演算法或行為,繼承於抽象類;新增一個輔助類來維護隊抽象類的引用(可有可無)。 關係圖如下:


抽象演算法類,Strategy類,定義所有支援的演算法的公共介面

        public abstract class Strategy{
     		 //演算法方法
     		 public abstract void AlgorithmInterface();
	}
三個具體實現類
public class ConcreteStrategyA extends  Strategy{
          //演算法A實現方法
          @Override
          public void AlgorithmInterface(){
                //演算法A的實現
          }
}

public class ConcreteStrategyB extends  Strategy{
          //演算法B實現方法
          @Override
          public void AlgorithmInterface(){
                //演算法B的實現
          }
}

public class ConcreteStrategyC extends  Strategy{
          //演算法C實現方法
          @Override
          public void AlgorithmInterface(){
                //演算法C的實現
          }
}

public class Context{
        Strategy strategy;
        public Context(Strategy strategy){
              this.strategy=strategy;
        }
        public void ContextInterface(){
                 strategy.AlgorithmInterface();
        }
}
測試類
  1. publicclass StrategyTest {  
  2.     publicstaticvoid main(String[] args) {  
  3. Context context;
  4.         context=new Context(new ConcreteStrategyA());
  5.         context.ContextInterface();
  6. context=new Context(new ConcreteStrategyB());
  7.         context.ContextInterface();
  8.         .......
  9.     }  
總結:策略模式的決定權在使用者,系統本身提供不同演算法的實現,新增或者刪除演算法,對各種演算法做封裝。因此,策略模式多用在演算法決策系統中,外部使用者只需要決定用哪個演算法即可。

相關推薦

Java面向物件設計模式十三——策略模式strategy

策略模式(strategy) 策略模式定義了一系列演算法,並將每個演算法封裝起來,使他們可以相互替換,且演算法的變化不會影響到使用演算法的客戶。         一種方法是 需要設計一個介面,為

Java面向物件設計模式——工廠方法模式

工廠方法模式(Factory Method) 工廠方法模式分為三種: 1、普通工廠模式,就是建立一個工廠類,對實現了同一介面的一些類進行例項的建立。首先看下關係圖: 舉例如下:(我們舉一個傳送郵件和簡訊的例子) 首先,建立二者的共同介面: publici

Java面向物件設計模式

設計模式(Design Patterns)   ——可複用面向物件軟體的基礎       設計模式(Design pattern)是一套被反覆使用、多數人知曉的、經過分類編目的、程式碼設計經驗的

java面向物件——設計原則

1. 開閉原則 (open close principle) 對擴充套件開放,對修改關閉。在程式需要進行擴充套件的時候,不能去修改原有的程式碼,即實現一個熱拔插效果。 為了使程式的擴充套件性更好,易

Java面向物件設計原則

1. 面向抽象原則 1.1 抽象類 特點:         1.抽象類中的abstract方法可有可無,也可以有非abstract方法         2.抽象類不能用new建立物件         3.抽象類的非抽象子類必須重寫父類的abstract方法  

Java面向物件設計

面向物件設計的SOLID原則: S.O.L.I.D是面向物件設計和程式設計(OOD&OOP)中幾個重要編碼原則(Programming Priciple)的首字母縮寫。 SRP The Single Responsibility Principle :單一責任原則

JAVA面向物件設計例項之一發牌比較大小

程式功能闡述如下:由電腦隨機從撲克牌堆中抽取前兩張牌,一張屬於使用者,一張屬於電腦,比較其大小:      大小規則:數字規則:                           2<3<4<5<6<7<8<9<10<J

嘮嘮面試常問的,Java 面向物件設計的六大原則

這篇文章主要講的是面向物件設計中,我們應該遵循的六大原則。只有掌握了這些原則,我們才能更好的理解設計模式。 我們接下來要介紹以下6

面向物件設計設計模式:結構型模式附 Demo & UML類圖

本篇是面向物件設計系列文章的第三篇,講解的是設計模式中的結構型模式: 外觀模式 介面卡模式 橋接模式 代理模式 裝飾者模式 享元模式 該系列前面的兩篇文章: 面向物件設計的六大設計原則(附 Demo 及 UML 類圖) 面向物件設計的設計模式(一):建

Java面向物件與多執行緒綜合實驗之GUI設計

瞭解Java圖形介面程式的基本結構;掌握Java佈局管理和常用元件的使用;掌握Java事件處理機制。 實驗內容 編寫程式,將前面課程所編寫的檔案管理系統改編為圖形使用者介面。要求程式介面選用合適的佈局,綜合使用選單、按鈕、文字框、密碼框、下拉列表、檔案對話方塊等元件,實現良好的人機介面。

java程式猿應該瞭解的10個面向物件設計原則每次看都很有感悟,特意拿來和大家共享

Java程式設計最基本的原則就是要追求高內聚和低耦合的解決方案和程式碼模組設計。檢視Apache和Sun的開放原始碼能幫助你發現其他Java設計原則在這些程式碼中的實際運用。 面向物件設計原則是OOPS(Object-Oriented Programming System,

PHP面向物件程式設計設計模式策略模式

(一)什麼是面向物件程式設計   面向物件(OO)的定義是什麼,在面向物件的入門課程C++(或者JAVA)中,封裝資料和方法好像是面向物件最重要的一個特點,當然還有基於繼承實現的多型和過載。其實每一種OOP語言,由於彼此功能上的差異性,這些特點只能適用於某一種

基本設計模式學習筆記:常見的七種面向物件設計原則

0.概述      面向物件設計原則為支援可維護性複用而誕生,這些原則蘊含在很多設計模式中,他們是從許多設計方案中總結出來的指導性原則1.單一原則     一個類只負責一個功能領域中的相應職責,或者說:就一個類而言,應該只有一個引起它變化的原因。個人總結:將不同職責的方法放在

java設計模式策略模式

() pan win with blog trac java設計模式 ring ide   策略模式定義了一系列的算法,並將每一個算法封裝起來,而且使它們可以相互替換,讓算法獨立於使用它的客戶而獨立變化,具體應用場景如第三方支付對接不同銀行的算法。   要點:1)抽象策略角

Java 設計模式學習筆記1——策略模式Duck例子

利用 實例化 top 而是 實現 學習筆記 left ng- 多個 0、假設現有工程(Duck)中遇到為類添加功能的問題,如何設計類添加新的功能? 1、利用繼承提供的Duck(鴨子)的行為會導致哪些缺點? (1)代碼在多個子類中重復 (2)很多男知道所有鴨子的全部行為

C#設計模式十三模板方法模式Template Method Pattern【行為型】

並集 client 變化 args 集中 pac 爸爸 rim 自己 原文:C#設計模式之十三模板方法模式(Template Method Pattern)【行為型】一、引言 “結構型”的設計模式已經寫完了,從今天我們開始講“行為型”設計模式。現在我們開始講【行為型】設

面向物件設計原則 開放封閉原則Open Closed Principle

開放封閉原則(OCP,Open Closed Principle)是所有面向物件原則的核心。   軟體設計本身所追求的目標就是封裝變化、降低耦合,而開放封閉原則正是對這一目標的最直接體現。 其他的設計原則,很多時候是為實現這一目標服務的,例如以里氏替換原則實現最佳的、正確的繼承層次,就能保證不

面向物件設計原則 依賴倒置原則Dependency Inversion Principle

依賴倒置原則(Dependence Inversion Principle)是程式要依賴於抽象介面,不要依賴於具體實現。 簡單的說就是要求對抽象進行程式設計,不要對實現進行程式設計,這樣就降低了客戶與實現模組間的耦合。   面向過程的開發

面向物件設計原則 介面分離原則Interface Segregation Principle

介面隔離原則   使用多個專門的介面,而不使用單一的總介面,即客戶端不應該依賴那些它不需要的介面。   從介面隔離原則的定義可以看出,他似乎跟SRP有許多相似之處。 是的其實ISP和SRP都是強調職責的單一性, 介面隔離原則告訴我們在定義介面的時候要根據職責定義“較小”的介面

Java面向物件模板方法溫習final、abstract

 /*  * 當代碼完成優化後,就可以解決這類問題  * 這種方式就是模板方法:  *     在定義功能時,功能一部分是確定的,但有一部分是不確定的,而確定的部分在使用不確定的部分,  * 那麼這時就將不確定的部分