在平時開發中，往往會遇到這樣一種情況，實作一種功能有很多種演算法或策略，我們可以根據不同的演算法或策略來實現這種功能。例如：想要計算一種計算物流的計算方式，都是計費，不同的快遞有不同的計費方式，像京東快遞、百世快遞、圓通快遞。它們之間計算運費的方式都是不同的。那我們要怎麼實現呢？簡單的就是if...else...或switch...case...。這兩種實作方式稱之為硬編碼。如果又新增了一種計費方式像韻達快遞，那就要去修改我們演算法的原始碼。這樣會使代碼變的較為臃腫，維護困難。
所以，我們需要想要實作一種方式就是各自有各自的演算法，只需要在客戶端選擇哪一種方式去呼叫就好了。
環境類別（Context）：用一個ConcreteStrategy物件來配置。維護一個對Strategy物件的參考。可以定義一個介面來讓Strategy存取他的資料。
抽象策略類別（Strategy）：定義所有支援演算法的公共介面。 Context使用這個介面來呼叫某ConcreteStrategy定義的演算法。
具體策略類別（ConcreteStrategy）：以Strategy介面實作具體的演算法。
以不同快遞公司運費為例：
步驟一：定義一個抽象策略類別（計費方式）
public interface CommandStrategy {
/**
* 计费方式
* @param message
*/
void calMoney(String message);
}步驟二：定義具體的策略類別（不同演算法類別實作此介面）
public class BaiShiCommand implements CommandStrategy {
/**
* 百世快递计费方式
* @param message
*/
@Override
public void calMoney(String message) {
System.out.println("百世快递收费方式："+"起步20，每公斤6元");
}
}public class JingDongCommand implements CommandStrategy {
/**
* 京东快递计费方式
* @param message
*/
@Override
public void calMoney(String message) {
System.out.println("京东快递收费方式："+"起步30，每公斤5元");
}
}public class YuanTongCommand implements CommandStrategy {
/**
* 圆通快递计费方式
* @param message
*/
@Override
public void calMoney(String message) {
System.out.println("圆通快递收费方式："+"起步10，每公斤8元");
}
}步驟三：定義環境類別
public class CommandContext {
public CommandStrategy getInstance(String commandType) {
CommandStrategy commandStrategy = null;
Map<String, String> allClazz = CommandEnum.getAllClazz();
//拿到对应算法类对应的路径
String clazz = allClazz.get(commandType.trim().toLowerCase());
if (StringUtils.isNotEmpty(clazz)) {
try {
try {
//创建一个对象实例
commandStrategy = (CommandStrategy) Class.forName(clazz).newInstance();//调用无参构造器创建实例
} catch (InstantiationException | IllegalAccessException e) {
e.printStackTrace();
}
} catch (ClassNotFoundException e) {
e.printStackTrace();
}
}
System.out.println("commandStrategy:"+commandStrategy);
return commandStrategy;
}
}定義一個列舉類別：
public enum CommandEnum {
JingDong("京东", "com.liubujun.design.command.JingDongCommand"), BaiShi("百世", "com.liubujun.design.command.BaishiCommand"), YuanTong("圆通", "com.liubujun.design.command.YuanTongCommand");
private String name;
private String clazz;
public static Map<String, String> getAllClazz() {
Map<String, String> map = new HashMap<>(8);
System.out.println("==================="+Arrays.toString(CommandEnum.values())+"================");
for (CommandEnum commandEnum : CommandEnum.values()) {
map.put(commandEnum.getCommand(), commandEnum.getClazz());
}
return map;
}
public String getCommand() {
return name;
}
CommandEnum(String command, String clazz) {
this.name = command;
this.clazz = clazz;
}
public void setCommand(String command) {
this.name = command;
}
public String getClazz() {
return clazz;
}
public void setClazz(String clazz) {
this.clazz = clazz;
}
}客戶端：
public class MainStart {
public static void main(String[] args) {
String message = "京东";
CommandContext commandContext = new CommandContext();
//拿到message对应算法的对象实例
CommandStrategy commandStrategy = commandContext.getInstance(message);
commandStrategy.calMoney(message);
}
}這樣在客戶端就可以直接呼叫哪一種快遞的計費方式了
優點：
1) 相關演算法系列Strategy類別層次為Context定義了一系列的可供重複使用的演算法或行為。繼承有助於析取出這些演算法中的公共功能。
2) 提供了可以取代繼承關係的方法： 繼承提供了另一種支援多種演算法或行為的方法。你可以直接產生一個Context類別的子類，從而給它不同的行為。但這會將行為硬行編製到 Context中，而將演算法的實作與Context的實作混合起來,從而使Context難以理解、難以維護和難以擴展，而且還不能動態地改變演算法。最後你得到一堆相關的類別 , 它們之間的唯一差異是它們所使用的演算法或行為。將演算法封裝在獨立的Strategy類別中使得你可以獨立於其Context改變它，使它易於切換、易於理解、易於擴展。
3) 消除了一些if else條件語句 ：Strategy模式提供了用條件語句選擇所需的行為以外的另一種選擇。當不同的行為堆砌在一個類別中時 ,很難避免使用條件語句來選擇適當的行為。將行為封裝在一個獨立的Strategy類別中消除了這些條件語句。含有許多條件語句的程式碼通常意味著需要使用Strategy模式。
4) 實作的選擇 Strategy模式可以提供相同行為的不同實作。客戶可以根據不同時間 /空間權衡取捨要求從不同策略中進行選擇。
缺點：
1)客戶端必須知道所有的策略類，並自行決定使用哪一個策略類: 本模式有一個潛在的缺點，就是一個客戶要選擇一個合適的Strategy就必須知道這些Strategy到底有何不同。此時可能不得不向客戶揭露具體的實作問題。因此僅當這些不同行為變體與客戶相關的行為時 , 才需要使用Strategy模式。
2 ) Strategy和Context之間的通訊開銷 ：無論各個ConcreteStrategy實現的演算法是簡單還是複雜, 它們都共享Strategy定義的介面。因此很可能某些 ConcreteStrategy不會都用到所有透過這個介面傳遞給它們的資訊；簡單的 ConcreteStrategy可能不會使用其中的任何資訊！這意味著有時Context會建立和初始化一些永遠不會用到的參數。如果有這樣問題 , 那麼將需要在Strategy和Context之間更進行緊密的耦合。
3 )策略模式將造成產生許多策略類別：可以透過使用享元模式在一定程度上減少物件的數量。增加了物件的數目 Strategy增加了一個應用中的物件的數目。有時你可以將 Strategy實作為可供各Context共享的無狀態的物件來減少這一開銷。任何其餘的狀態都由 Context維護。 Context在每一次對Strategy物件的請求中都將這個狀態傳遞過去。共享的 Strategy不應在各次呼叫之間維護狀態。
以上是Java 設計模式之策略模式的實作方式的詳細內容。更多資訊請關注PHP中文網其他相關文章！
