為什么要使用設(shè)計模式

因為我們的項目的需求是永遠(yuǎn)在變的，為了應(yīng)對這種變化，使得我們的代碼能夠輕易的實現(xiàn)解耦和拓展。如果能夠保證代碼一次寫好以后都不會再改變了，那可以想怎么寫怎么寫了。

[[320551]]

如何判斷那里需要使用設(shè)計模式

在我們實現(xiàn)中，有一些代碼是一次寫好后續(xù)基本不會改變的，或者不太需要擴展的，比如一些工具類等。有一部分是會經(jīng)常變得，設(shè)計模式大多都應(yīng)用在需求會變化的這一部分。分析這些代碼會如何變，選擇合適的設(shè)計模式來優(yōu)化這部分代碼。

以促銷活動需求為例

需求

為了促進商品的銷售，各大電商品臺會在平時或者一些節(jié)日的時候退出一些促銷活動刺激用戶消費，活動的類型可能會各不相同，如下：

• 滿減，滿400減20
• 代金卷，瑪莎拉蒂5元代金卷
• 折扣，9折，8折
• 每滿減，每滿200減10
• 等等

其中有些可以疊加，有些只能單獨使用。

簡單實現(xiàn)

上面的需求看起來還是比較簡單的，但是如果考慮到我們是不可能一次定義好所有的促銷活動類型，后續(xù)我們可能會隨時都添加新的類型，要保證能夠簡單的實現(xiàn)功能擴展，那就比較麻煩了。Spring 框架用到的 9 個設(shè)計模式匯總，這個你知道嗎?

先拿到需求的時候，也不用去想那么多，挽起袖子就是一通操作：

public class OrderPromotion {   
   
    public BigDecimal promotion(Order order, int[] promotions){   
        for(int promotion:promotions){   
            switch (promotion){   
                case 1:   
                    //計算該類型折扣后的價格   
                    break;   
                case 2:   
                    //計算該類型折扣后的價格   
                    break;   
                case 3:   
                    //計算該類型折扣后的價格   
                    break;   
                //....   
            }   
        }   
        return order.getResultPrice();   
    }   
} 

單從功能實現(xiàn)上來說，上面的代碼已經(jīng)完成了基本功能了。

但是上面的代碼也是致命的，雖然看起來很簡單，但是那只不過是因為大多數(shù)功能都用注釋代替了，換成實際代碼的話一個方法可能就得上千行。

尤其是當(dāng)我們需要添加新的促銷活動的話就需要在switch中添加新的類型，這對于開發(fā)來說簡直是災(zāi)難，并且維護這些代碼也是一個麻煩。

優(yōu)化一：單一職責(zé)原則

上面的代碼中，promotion(…)方法直接完成了所有的工作，但是咋我們實際實現(xiàn)中最好讓一個方法的職責(zé)單一，只完成某一個功能，所以這里我們將對折扣類型的判斷和計算價格分開：

public class OrderPromotion {   
   
    public BigDecimal promotion(Order order, int[] promotions){   
        for(int promotion:promotions){   
            switch (promotion){   
                case 1:   
                    calculate1(order);   
                    break;   
                case 2:   
                    calculate2(order);   
                    break;   
                case 3:   
                    calculate3(order);   
                    break;   
                //more promotion   
            }   
        }   
        return order.getResultPrice();   
    }   
   
    public void calculate1(Order order){   
        //計算使用折扣一后的價格   
    }   
   
    public void calculate2(Order order){   
        //計算使用折扣二后的價格   
    }   
   
    public void calculate3(Order order){   
        //計算使用折扣三后的價格   
    }   
   
    //more calculate   
   
} 

這里我們將折扣類型的判斷和計算價格分開，使得promotion(…)方法的代碼量大大降低，提升了代碼的可讀性。面象對象設(shè)計6大原則之一：單一職責(zé)原則，這篇也推薦大家看下。

優(yōu)化二：策略模式

上面優(yōu)化后的代碼提升了原有代碼的可讀性，但是原來OrderPromotion類代碼大爆炸的問題還是沒有解決。

針對這個問題，我們希望能夠?qū)⒂嬎愕拇a和當(dāng)前代碼分離開，首先我們能想到的就是定義一個類，然后將計算的代碼復(fù)制到這個類中，需要的時候就調(diào)用。這樣到的確是分離開了，但是完全是治標(biāo)不治本。在添加新的促銷活動是兩個類都要改。

所以我們希望能夠?qū)⒉煌拇黉N活動的實現(xiàn)分離開，這樣對每一種活動的實現(xiàn)都是分開的，修改也不會影響其他的，基于此我們完全可以選擇策略模式來實現(xiàn)。

策略模式

策略模式的思想是針對一組算法，將每一種算法都封裝到具有共同接口的獨立的類中，從而是它們可以相互替換。策略模式的最大特點是使得算法可以在不影響客戶端的情況下發(fā)生變化，從而改變不同的功能。

public class OrderPromotion {   
   
    public BigDecimal promotion(Order order, int[] promotions){   
        for(int promotion:promotions){   
            switch (promotion){   
                case 1:   
                    new PromotionType1Calculate(order);   
                    break;   
                case 2:   
                    new PromotionType1Calculate(order);   
                    break;   
                case 3:   
                    new PromotionType1Calculate(order);   
                    break;   
                //more promotion   
            }   
        }   
        return order.getResultPrice();   
    }   
} 

上面的代碼很明顯已經(jīng)精簡很多了，到了現(xiàn)在如果需要添加一個促銷活動的話只需定義一個促銷類，實現(xiàn)PromotionCalculation接口然后在switch中添加即可。

優(yōu)化三：工廠模式

上面的代碼雖然已經(jīng)將促銷活動的實現(xiàn)分離開了，但是OrderPromotion還是一直在變得，每一次添加或者下線活動都需要修改該類。

現(xiàn)在我們希望OrderPromotion是不變的，將PromotionCalculation的實例化剝離開來。創(chuàng)建類很明顯是使用工廠設(shè)計模式了。

OrderPromotion

public class OrderPromotion {   
   
    public BigDecimal promotion(Order order, int[] promotions){   
        for(int promotion:promotions){   
            PromotionFactory.getPromotionCalculate(promotion).calculate(order);   
        }   
        return order.getResultPrice();   
    }   
} 

類的創(chuàng)建工作交給工廠來實現(xiàn)。

public class PromotionFactory {   
   
    public static PromotionCalculate getPromotionCalculate(int promotion){   
        switch (promotion){   
            case 1:   
                return new PromotionType1Calculate(order);   
            break;   
            case 2:   
                return new PromotionType1Calculate(order);   
            break;   
            case 3:   
                return new PromotionType1Calculate(order);   
            break;   
            //more promotion   
        }   
        return null;   
    }   
} 

使用工廠模式后OrderPromotion類就不需要改了，每一次添加新的促銷活動后只需要在工廠類中添加即可。

優(yōu)化四：配置+反射

上面的代碼還存在的問題在于每一次需要添加新的促銷活動的時候還是需要修改工廠類中的代碼，這里我們通過配置文件加反射的方式來解決。

定義映射配置文件

mapping.properties

1=design.order.PromotionType1Calculate   
2=design.order.PromotionType2Calculate   
3=design.order.PromotionType3Calculate 

PromotionFactory

public class PromotionFactory {   
   
    private static Map<Integer, String> mapping = new HashMap<Integer, String>();   
   
    static {   
        try {   
            Properties pps = new Properties();   
            pps.load(new FileInputStream("Test.properties"));   
            Iterator<String> iterator = pps.stringPropertyNames().iterator();   
            while(iterator.hasNext()){   
                String key=iterator.next();   
                mapping.put(Integer.valueOf(key), pps.getProperty(key));   
            }   
        } catch (IOException e) {   
            e.printStackTrace();   
        }   
    }   
   
    public static PromotionCalculate getPromotionCalculate(int promotion) throws Exception {   
        if(mapping.containsKey(promotion)){   
            String beanName = mapping.get(promotion);   
            return Class.forName(beanName).newInstance();   
        }   
        return null;   
    }   
} 

通過上面的代碼就可以實現(xiàn)不改變已有代碼的前提下實現(xiàn)對功能的靈活擴展。當(dāng)然，這里的代碼只是作為演示用的，實際上可以改進的地方還有不少，像最后反射效率較低，也可以通過其他的方式來實現(xiàn)。

小結(jié)

設(shè)計模式是我們一定要了解的東西，熟悉設(shè)計模式能讓我們設(shè)計出易于擴展和維護的代碼結(jié)構(gòu)。但是并不是任何地方都需要上設(shè)計模式，應(yīng)該結(jié)合我們的項目實際進行分析是否需要設(shè)計模式，使用哪種設(shè)計模式。