工廠模式和政策模式

剛剛接觸設計模式的時候，我相信單例模式和工廠模式應該是用的最多的，畢竟很多的底層代碼幾乎都用了這些模式。自從接觸了一次阿裡的公衆号發的一次文章關于 DDD的使用 以後，就逐漸接觸了政策模式。現在在項目中運用最多的也是這幾種設計模式了，用了設計模式給我的感受就是感覺代碼沒那麼備援了，再注入一點貧血，充血模型之後，感覺在 service 層面代碼看上去很舒服很簡潔。

首先，我個人感覺政策模式和我們常說的微服務我覺得思想上很像，尤其記得當時介紹DDD時候的舉例說的是關于銀行的轉賬案例，用的事務和領域驅動設計做的比較，讓人一目了然的邏輯，代碼也再也沒有那麼備援了。（具體的文章位址找不到了，不過網上現在比較多的介紹DDD的，大體意思是一樣的）

其實工廠模式和設計模式一直給人一種錯覺，總感覺是一樣的，沒有絲毫的差別。可以看下兩種模式的UML圖

從圖上來看，并沒有多大的差別，話不多說，從具體的代碼入手。

先寫一個人的接口類，有eat，run，wear 3個方法

public interface People {
 
    public void eat();
 
    public void run();
 
    public void wear();
}      

分别寫兩個實作類，一個是小明的實作類，一個是小紅的實作類

public class Xiaoming implements People{
 
    @Override
    public void eat() {
        System.out.println("小明吃飯");
    }
 
    @Override
    public void run() {
        System.out.println("小明跑步");
    }
 
    @Override
    public void wear() {
        System.out.println("小明穿衣");
    }
}
 
 
public class Xiaohong implements People{
 
    @Override
    public void eat() {
        System.out.println("小紅吃飯");
    }
 
    @Override
    public void run() {
        System.out.println("小紅跑步");
    }
 
    @Override
    public void wear() {
        System.out.println("小紅穿衣");
    }
}      

簡單工廠模式的代碼

public class PeopleFactory {
 
    public People getPeople(String name){
        if(name.equals("Xiaoming")){
            return new Xiaoming();
        }else if(name.equals("Xiaohong")){
            return new Xiaohong();
        }
        return null;
    }
}      

再來看下政策模式的代碼

public class StrategySign {
 
    private People people;
 
    public StrategySign(People people){
        this.people = people;
    }
 
    public StrategySign(String name){
        if(name.equals("Xiaoming")){
            this.people = new Xiaoming();
        }else if(name.equals("Xiaohong")){
            this.people = new Xiaohong();
        }
    }
 
    public void run(){
        people.run();
    }
}      

政策模式的兩種構造方法都可以用，我多寫了一種是為了讓大家看到和工廠模式的差別和聯系

然後我們通過測試類運作兩種模式

@Test
    public void testSign(){
        PeopleFactory peopleFactory = new PeopleFactory();
        People people = peopleFactory.getPeople("Xiaohong");
        System.out.print("工廠模式-------------"); people.run();
        StrategySign strategySign = new StrategySign("Xiaohong");
        System.out.print("政策模式-------------");strategySign.run();
    }      

可以看到，兩種設計模式的運作結果是一模一樣的，那麼差別到底在哪呢。

從工廠模式的代碼中可以看到 工廠模式主要是傳回的接口實作類的執行個體化對象，最後傳回的結果是接口實作類中的方法，而政策模式是在執行個體化政策模式的時候已經建立好了，我們可以再政策模式中随意的拼接重寫方法，而工廠模式是不管方法的拼接這些的，他隻關注最後的結果，不注重過程，而政策模式注重的是過程。

用一個具體的例子可以看下，如果我想小紅先吃飯再跑步再吃飯的話，那麼我需要在測試類中寫3種，而我隻需要在政策模式的方法中直接定義即可。

可以看以下代碼：

public class StrategySign {
 
    private People people;
 
    public StrategySign(People people){
        this.people = people;
    }
 
    public StrategySign(String name){
        if(name.equals("Xiaoming")){
            this.people = new Xiaoming();
        }else if(name.equals("Xiaohong")){
            this.people = new Xiaohong();
        }
    }
 
    public void run() {
        people.eat();
        people.run();
        people.eat();
    }
}
 
@Test
    public void testSign(){
        PeopleFactory peopleFactory = new PeopleFactory();
        People people = peopleFactory.getPeople("Xiaohong");
        System.out.print("工廠模式-------------"); people.eat();
        System.out.print("工廠模式-------------"); people.run();
        System.out.print("工廠模式-------------"); people.eat();
        StrategySign strategySign = new StrategySign("Xiaohong");
        System.out.print("政策模式-------------");strategySign.run();
    }      

有人可能會說如果我在實作類中直接拼接好這些方法不是就好了麼？可是那樣的話我們每變更一次邏輯就要新增一個方法，一次兩次還好，但是當邏輯多了以後，這些代碼會變得很備援，難以維護。而且從目前情況來看，工廠模式可以做到的事情，政策模式都可以做到。政策模式可以做到的事情，工廠模式也可以做到，隻是會變得麻煩。

從上述的描述來看，政策模式就和我們常說的微服務很像，比如我們寫的3個接口，吃飯是一個微服務，跑步是一個微服務，穿衣是一個微服務。政策模式的宗旨就是将各項方法之間連接配接起來，達到一個新的方法，微服務的宗旨也是防止服務的多次調用，降低代碼的耦合度，是以這麼看來政策模式和微服務還是比較相像的。