Java深入講解二十三種設計模式之中的策略模式

2022-05-26 14:01:02

1 概述

在平時開發中，往往會遇到這樣一種情況，實現一種功能有很多種演演算法或者策略，我們可以根據不同的演演算法或者策略來實現這種功能。比如：想要計算一種計算物流的計算方式，都是計費，不同的快遞有不同的計費方式，像京東快遞、百世快遞、圓通快遞。它們之間計算運費的方式都是不同的。那我們怎麼來實現呢？簡單的就是if...else...或者switch...case...。這兩種實現方式被稱之為寫死。如果又新增了一種計費方式像韻達快遞，那麼就要去修改我們演演算法的原始碼。這樣會使程式碼變的較為臃腫，維護困難。

所以，我們需要想要實現一種方式就是各自有各自的演演算法，只需要在使用者端選擇哪種方式去呼叫就好了。

2 策略模式

2.1 組成部分

環境類（Context）：用一個ConcreteStrategy物件來設定。維護一個對Strategy物件的參照。可以定義一個介面來讓Strategy存取他的資料。

抽象策略類（Strategy）：定義所有支援演演算法的公共介面。Context使用這個介面來呼叫某ConcreteStrategy定義的演演算法。

具體策略類（ConcreteStrategy）：以Strategy介面實現具體的演演算法。

2.2 程式碼範例

以不同快遞公司運費為例：

步驟一：定義一個抽象策略類（計費方式）

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);
    }
}

這樣在使用者端就可以直接呼叫哪一種快遞的計費方式了

2.3 優缺點

優點：

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深入講解二十三種設計模式之中的策略模式的文章就介紹到這了,更多相關Java策略模式內容請搜尋it145.com以前的文章或繼續瀏覽下面的相關文章希望大家以後多多支援it145.com！