設計模式（Design Pattern）——政策模式

Tags:

[java, 設計模式, 政策]

  設計模式也是老生常談的話題了，這裡老衲也就做一個自己歸納的小結論，設計模式其實就是程式設計經驗複用，不局限于某一門語言，是一種思想，一種解決問題的思路，所謂正常的設計模式不過是前人總結出來的程式設計經驗，要學習解決這些問題的經驗，更要學習碰到問題應該有何種思考，從哪方面入手，設計契合應用場景的子產品架構來。

  常例，如果您看完本文引起了強烈的“身體不适”，還請往[email protected]扔出您的問題，評論功能老衲就懶得內建了哈~

設計原則

請先記住一句話：軟體的開發周期和維護周期相比，開發所用時間和維護疊代時間相比要少很多，是以我們代碼的設計核心應該放在提高可維護性和可擴充性的複用程度

* 找出應用中可能需要變化的部分，把他們獨立出來，不要和不需要變化的代碼混合在一起

* 針對接口程式設計，而不是針對實作程式設計

* 多用組合，少用繼承

切入本篇正題，政策模式

政策模式定義了算法族，分别封裝起來，讓他們之間可以互相替換，此模式讓算法的變化獨立于使用算法的調用者。OK,廢話不多說，直接上代碼，通俗易懂

首先，我們來設計一種應用場景，就拿付錢來說吧，每個人都會為自己的生活買單，買單的方式也多種多樣，總結起來，大概是現金和刷卡。那麼，我們就來定義一個付錢的借口來。

public interface PayStrategy {
        /**
         * pay for anything
         */
        void pay();
    }
           

OK，簡單粗暴，付錢嘛

接下來，我們為之前的應用場景來搞幾個實作這些付款方式的實作類咯~

private static class CashPay implements PayStrategy {

        @Override
        public void pay() {
            System.out.println("現金付款");
        }
    }

    private static class CardPay implements PayStrategy {

        @Override
        public void pay() {
            System.out.println("刷卡付款");
        }
    }

    private static class FacePay implements PayStrategy {

        @Override
        public void pay() {
            System.out.println("臉付");
        }
    }
           

最後，我們來定義一下具備付款條件的東西，那就是人咯~

private static class Person {

    private PayStrategy payStrategy;

    public Person(String identity) {
        setPayStrategy(identity);
    }

    public void pay() {
        this.payStrategy.pay();
    }

    /**
     * 設定付款人身份
     *
     * @param identity translate param's name
     */
    private void setPayStrategy(String identity) {
        switch (identity) {
            case "richer":
                System.out.println("我是土豪");
                this.payStrategy = new CardPay();
                break;
            case "bricker":
                System.out.println("我是搬磚工");
                this.payStrategy = new CashPay();
                break;
            case "mayun":
                System.out.println("老子是馬雲爸爸");
                this.payStrategy = new FacePay();
                break;
            default:
                break;
        }
    }
}
           

這裡老衲就圖個友善直接粘貼過來了哈，構造裡面直接傳遞付款人的身份，當然我們這裡的話付款人就簡單定義3個了，分别是土豪，搬磚工和馬雲爸爸咯。土豪就刷卡，搬磚工就現金咯，馬雲爸爸這種級别我也不知道，都有可能吧，姑且就給個臉卡吧。（注：這裡這是例子，和命名無絲毫關系，噴子退下吧~）

接下來就來run一把爽爽吧

public static void main(String[] args) {
        Person tuhao = new Person("richer");
        tuhao.pay();
        Person banzhuangong = new Person("bricker");
        banzhuangong.pay();
        Person mayun = new Person("mayun");
        mayun.pay();
}
           

運作結果如下

我是土豪
刷卡付款
我是搬磚工
現金付款
老子是馬雲爸爸
臉付
           

好了，編碼就那麼簡單粗暴，您要是沒看懂，就再看一遍，下面老衲說一下自己對政策模式（Strategy）的見解

* 首先，付款這項技能就跟普通攻擊似得，誰都會，就是咱們的base算法。

* 然後就是更新加點了呗，先會現金，然後刷卡，然後就開大直接臉付了呗。這一類加點技能的話其實就是咱們術語裡面的算法族。

* 付款者們無需知道怎麼付錢，他們隻要付錢即可，沒有卡，你的手自然而然掏腰包咯，有卡，自然實力裝一波刷卡咯，當生命中沒有了錢的概念的時候，哥們，臉即可。

那麼唧唧歪歪下來這麼多有什麼卵用賴？

  其實說白了就是這麼寫，可以去動态的改變你執行個體所産生的行為，需求發生變更的時候，你可以增加政策，然後讓調用者去配置這個新政策即可，缺點就是調用者要知道所有的政策，越來越多臃腫之後，你就會發現尼瑪自己都不知道調用哪個了，是以在應用此模式的時候一定要注意使用場景。

  非要推薦一波Android開發中所用到的政策的話，大哥，請借鑒ListView的setAdapter源碼，一看結構就能看出來，顯而易見，政策模式嘛，這裡就不貼過來了，挺樸實一個東西，整複雜了大家煩，寫起來也惡心，複雜的系統也是這些樸實的東西堆積起來的，把基礎的東西弄明白了，你也可以設計出複雜可靠的系統來，無他，唯手熟爾~（這裡有壞笑的emoj啊！）

  OK,拿去裝13不謝