設計模式-策略模式-有解無憂

示例

策略模式是我們作業中比較常用的一個設計模式，但是初次理解起來可能會有點困難，因此我們還是先看一個例子，假設現在需要開發一個畫圖工具，畫圖工具中有鋼筆，筆刷和油漆桶，其中，鋼筆可以用于描邊，但不能填充，筆刷既可以描邊，也可以填充，油漆桶只能用于填充，但不能描邊，

看到這個需求，最容易想到的可能就是通過繼承方式實作了，即鋼筆，筆刷和油漆桶都繼承自畫圖工具，然后都實作描邊和填充功能，只不過鋼筆的填充方法什么都不做，油漆桶的描邊方法也什么都不做，（該部分在設計原則中有示例代碼，是當時的一個遺留問題）

但是仔細一想，好像哪里不對勁，因為鋼筆和油漆桶部分方法不實作，很明顯違背了里氏替換原則，而且，正常情況應該是畫圖工具有用鋼筆，筆刷，油漆桶畫圖的能力，而不是鋼筆，筆刷，油漆桶繼承自畫圖工具，因此，我們可以如下實作：

public class Graphics
{
    public void Stroke(ToolEnum tool)
    {
        switch (tool)
        {
            case ToolEnum.Pen:
                Console.WriteLine($"用鋼筆描邊圖形");
                break;
            case ToolEnum.Brush:
                Console.WriteLine($"用筆刷描邊圖形");
                break;
            case ToolEnum.Bucket:
                Console.WriteLine("油漆桶不能描邊圖形");
                break;
            default:
                throw new NotSupportedException("不支持的畫圖工具");
        }
    }
        
    public void Fill(ToolEnum tool)
    {
        switch (tool)
        {
            case ToolEnum.Pen:
                Console.WriteLine($"鋼筆不能填充圖形");
                break;
            case ToolEnum.Brush:
                Console.WriteLine($"用筆刷填充圖形");
                break;
            case ToolEnum.Bucket:
                Console.WriteLine("用油漆桶填充圖形");
                break;
            default:
                throw new NotSupportedException("不支持的畫圖工具");
        }
    }
}

通過上面列舉的方式，我們實作了讓畫圖工具具備描邊和填充的能力，但是這樣的switch-case(或者if-else)給擴展和維護都帶來了很大的麻煩，而且通過前面對其他設計模式的學習，我相信大家看到這樣的代碼，一定是不能接受的，起碼應該將Pen，Brush，Bucket定義成類并且繼承自同一個基類，然后組合到Graphics中來，而不是直接使用條件判斷，因為用組合代替繼承是我們學習設計模式程序中百試不爽的經驗，但是，這次好像不怎么靈了，因為，一旦這樣做，我們就又回到了原點---鋼筆和油漆桶不得不實作不需要的方法，事實上，用組合替代繼承是沒有錯的，但是該怎么組合？組合誰呢？這是個問題，感覺瞬間陷入了兩難的局面，這時候策略模式就派上用場了，它不抽象鋼筆、筆刷、油漆桶等具體事物，而是直接抽象描邊和填充這兩種能力，站在代碼的角度上看，就是將方法封裝成了物件（正應了那句一切皆物件），這正是策略模式最讓人費解，但又最妙不可言的地方，我們直接看看用策略模式改進后的代碼是怎樣的，先抽象能力：

public interface IStrokeStrategy
{
    void Stroke();
}

public class PenStrokeStrategy : IStrokeStrategy
{
    public void Stroke()
    {
        Console.WriteLine($"用鋼筆描邊圖形");
    }
}

public class BrushStrokeStrategy : IStrokeStrategy
{
    public void Stroke()
    {
        Console.WriteLine($"用筆刷描邊圖形");
    }
}

public interface IFillStrategy
{
    void Fill();
}

public class BrushFillStrategy : IFillStrategy
{
    public void Fill()
    {
        Console.WriteLine($"用筆刷填充圖形");
    }
}

public class BucketFillStrategy : IFillStrategy
{
    public void Fill()
    {
        Console.WriteLine("用油漆桶填充圖形");
    }
}

看到了嗎？直接將Stroke和Fill兩種能力定義成了介面，再通過不同的子類去實作這種能力，然后再看看Graphics類如何組合：

public class Graphics
{
    private IStrokeStrategy _strokeStrategy;
    private IFillStrategy _fillStrategy;
        
    public Graphics(IStrokeStrategy strokeStrategy,
                    IFillStrategy fillStrategy)
    {
        this._strokeStrategy = strokeStrategy;
        this._fillStrategy = fillStrategy;
    }

    public void Stroke()
    {
        this._strokeStrategy.Stroke();
    }
        
    public void Fill()
    {
        this._fillStrategy.Fill();
    }
}

畫圖工具直接擁有了兩種能力，但是跟鋼筆、筆刷、油漆桶沒有直接關系，也就是說，只要給畫圖工具一個填充的工具，就可以完成填充功能了，至于給的具體是筆刷還是油漆桶，或者其他什么東西，畫圖工具并不關心，而且，Graphics類中的條件判斷陳述句也都去掉了，隔離了變化，整個類都變得穩定了，
如下就是通過策略模式實作的類圖：

定義

再來看一下定義，策略模式定義一系列演算法，把他們一個個封裝起來，并且使他們可以互相替換，該模式使得演算法可以獨立于使用它的客戶程式而變化，

這里的一系列演算法就是不同的描邊和填充方式了，不同的描邊方式可以相互替換，不同的填充方式也可以相互替換，并且也可以方便的擴展更多的描邊和填充方式子類，

UML類圖

上面的例子中用到了兩組演算法，抽象簡化之后就得到了如下策略模式的UML類圖：

Context：策略背景關系，持有IStrategy的參考，負責和具體的策略實作互動；
IStrategy：策略介面，約束一系列具體的策略演算法；
ConcreteStrategy：具體的策略實作，

優點

策略可以互相替換；
解決switch-case、if-else帶來的難以維護的問題；
策略易于擴展，滿足開閉原則.

缺點

客戶端必須知道每一個策略類，增加了使用難度，
隨著策略的擴展，策略類數量會增多；

第一個缺點無法避免，因為策略模式的一大優點就是演算法可以相互替換，但是如果使用者連每個演算法代表的是什么意思，優缺點是什么都不知道，又如何替換呢？但第二個缺點卻可以通過結合工廠模式，由工廠模式創建具體的策略子類來進行一定程度的緩解，至于具體該怎么實作，這就是工廠模式的知識了，大家可以自行回憶一下，

應用場景

在業務場景中，商家促銷活動就非常適合用到策略模式了，因為，商家促銷打折可能存在會員折扣，節日折扣，生日折扣等等幾十種方式，而且在不同的條件下可以相互替換，
而非業務場景中，日志框架中我們可能會使用log4Net,NLog,Serilog等，而記錄位置也可能是控制臺，檔案，資料庫等；系統中的快取，可以用Redis做分布式快取，也可以用MemeryCache做本地快取等，這些場景也都非常適合使用策略模式，

總之，策略模式簡約但不簡單，學好它妙用無窮！

原始碼鏈接

轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/1078.html

標籤：設計模式

上一篇：行為型模式之解釋器模式

下一篇：詳解JAVA面向物件的設計模式（四）、外觀模式