工廠模式

• 2021 年 6 月 6 日
• 筆記
• 設計模式

簡單工廠模式

簡單工廠模式是由工廠對象決定創建哪一種產品，雖然不屬於23種設計模式，但是也是工廠模式進階的由來。

模擬場景：

暑假太過無聊，就自己在家打算做一個MP3播放器，其中包括播放器的程式設計也是自己來搞定的。如下結構

//歌曲播放介面
public interface ISong {
    void  Play();
}

//流行歌曲播放
public class PopularISong implements ISong {
    @Override
    public void Play() {
        System.out.println("接下來播放流行歌曲~");
    }
}

//古典歌曲播放
public class ClassicalSongs  implements ISong {
    @Override
    public void Play() {
        System.out.println("接下來播放古典歌曲~");
    }
}

//MP3播放操作
public class MP3 {
    public  enum  SongType
    {
       PopularSongType,//流行歌曲
       ClassicalSongsType//古典歌曲
       //....其他類型
    }
    public ISong Pay(SongType type)
    {
        if(type==SongType.PopularSongType)
        {
            return new PopularISong();
        }
        else if(type==SongType.ClassicalSongsType)
        {
            return new ClassicalSongs();
        }
        return  null;
    }
}

public class Text {
    public static void main(String[] args) {
        //用戶執行操作
        MP3 mp3=new MP3();
        mp3.Pay(MP3.SongType.PopularSongType).Play();
    }
}

程式終於寫完了~我在沙發上愜意的用MP3放著流行歌曲，奶奶走過來問我能不能放戲曲，我摸了摸腦袋，說：「也可以」。不過你得等我一下。

1個小時之後，經過重新拆卸硬體，編寫程式碼，增加了戲曲的類，又重新修改了MP3類中if else分支。

else  if(type==SongType.TraditionalOperaType)//戲曲
{
    //.....
}

給奶奶用了之後，很滿意還告訴我爸表揚我，我爸知道了嚷嚷要聽相聲。我心想這不是又要再去寫一遍程式碼…..這顯然不行。

簡單工廠模式中包含了必要的邏輯判斷，根據用戶選擇的條件動態實例化生成相關的類，明確區分了各自的職責和權力。但是這裡也違反了開放-封閉原則，工廠類集中了所有的邏輯判斷，一旦要增加一個還得修改客戶端的程式碼。

工廠模式

有了上述的經驗，我決定重新改寫程式，以防止他們又想聽其它類型的歌曲，我又要重新修改程式碼邏輯判斷。

//工廠類
public interface IFactory {
    ISong CreateSong();
}

//產品歌曲類
public interface ISong {
    void  Play();
}

具體工廠類：

//具體工廠類 用於創建流行歌曲
public class PopularSongFactory  implements  IFactory{
    @Override
    public ISong CreateSong() {
        return  new PopularISong();
    }
}

//具體工廠類 用於創建古典歌曲
public class ClassicalSongsFactory implements  IFactory{
    @Override
    public ISong CreateSong() {
        return new ClassicalSongs();
    }
}

具體歌曲類：

//具體歌曲類：古典
public class ClassicalSongs  implements ISong {
    @Override
    public void Play() {
        System.out.println("接下來播放古典歌曲~");
    }
}

//具體歌曲類：流行
public class PopularISong implements ISong {
    @Override
    public void Play() {
        System.out.println("接下來播放流行歌曲~");
    }
}

用戶操作層面：

public static void main(String[] args) {
    //用戶執行操作
    IFactory factory=new ClassicalSongsFactory();//古典工廠  只需要更改這裡的類型，選擇權交給用戶去生成對應的實例
    ClassicalSongs songs= (ClassicalSongs) factory.CreateSong();
    songs.Play();
}

工廠模式把要決定實例化哪一個工廠的選擇判斷放到了客戶端，保持了簡單工廠模式的優點又克服了缺點，不需要做大的變動就可以改變，降低了程式的耦合，但是每需要增加一個類型的時候，又需要創建一個產品和工廠。這個可以利用反射來解決分支判斷的問題。