作者 點(diǎn)先生 日期 2018.9.26

嘮個(gè)嗑

先給各位觀眾老爺?shù)纻€(gè)歉，在上一篇文章的末尾本來(lái)說(shuō)了這次要給大家分享代理模式，但是臣妾，做不到啊！ 最近公司給我了一個(gè)新項(xiàng)目，于是比較忙一點(diǎn)，再加上代理模式那邊的東西有點(diǎn)多，我有點(diǎn)懵逼的，靜態(tài)、動(dòng)態(tài)、遠(yuǎn)程、虛擬，還有個(gè)RMI，小機(jī)靈鬼兒的腦袋一時(shí)間處理不過(guò)來(lái)啊！

最近在搭建新項(xiàng)目的時(shí)候，參考了前輩的一些代碼。這一次看別人代碼的時(shí)候，更容易知道別人寫(xiě)著類的目的是干嘛，為啥要這樣寫(xiě)了，這就是學(xué)習(xí)設(shè)計(jì)模式之后的好處之一吧，我仍然會(huì)繼續(xù)加油。嘗到了一些甜頭，現(xiàn)在更有動(dòng)力了。你們的留言，討論，點(diǎn)贊更是我巨大的動(dòng)力。

雖然是中途改道來(lái)寫(xiě)工廠模式，但絕對(duì)不會(huì)讓各位觀眾老爺失望的！本次要講的是三種工廠模式（簡(jiǎn)單工廠模式，工廠方法模式，抽象工廠模式），以及相關(guān)模式源碼上的一些理解、擴(kuò)展。

什么是工廠模式

new！
準(zhǔn)確的說(shuō)，是代替new實(shí)例化具體類的一種模式。 接下來(lái)我將以“音樂(lè)廠牌創(chuàng)造音樂(lè)”為例子，由淺到深深入工廠模式。
至于為什么要用工廠模式我會(huì)邊講例子邊說(shuō)。

簡(jiǎn)單工廠模式

制作一首歌曲，確定歌曲風(fēng)格之后，就先要寫(xiě)詞譜曲，然后依次就是錄歌，剪輯，混音，就可以發(fā)型了。當(dāng)然也可以“不混，直接發(fā)”！Skr~。

public class MusicLabel {Song createSong(String type){Song song = null;if(type.equals("folk")){ song = new FolkSong();}else if(type.equals("rock")){song = new RockSong();}else if(type.equals("pop")){song = new PopSong();}song.prepare();//作詞作曲演奏song.Sing(); //錄歌song.Cut(); //剪輯song.Mix(); //混音return song;} } 復(fù)制代碼

這樣寫(xiě)，有沒(méi)有問(wèn)題？ 沒(méi)有！ 不出bug能跑就完事兒了。科科。
然而這樣卻違反了開(kāi)閉原則：對(duì)擴(kuò)展開(kāi)放，對(duì)修改關(guān)閉。
我們可以把易變化的部分跟不變化的部分分開(kāi)。也就是將new對(duì)象的部分提出來(lái)，單獨(dú)形成一個(gè)類(工廠)。

public class SongFactory {public Song orderSong(String type){Song song = null;if(type.equals("folk")){song = new FolkSong();}else if(type.equals("rock")){song = new RockSong();}else if(type.equals("pop")){song = new PopSong();}return song;} } 復(fù)制代碼

在這兒有另外一種方法：利用靜態(tài)方法定義一個(gè)簡(jiǎn)單工廠(靜態(tài)工廠)。
這樣就不需要使用創(chuàng)建對(duì)象的方法來(lái)實(shí)例化對(duì)象。但這樣也有一個(gè)缺點(diǎn)：不能通過(guò)繼承來(lái)改變創(chuàng)建方法的行為。

修改之后重寫(xiě)MusicLabel類

public class MusicLabel {SongFactory factory;public MusicLabel(SongFactory factory) {this.factory = factory;}Song createSong(String type){Song song = null;song = factory.orderSong(type);song.prepare();song.Sing();song.Cut();song.Mix();return song;} } 復(fù)制代碼

這樣一來(lái)就將面向具體編程，變成了面向接口編程。

在設(shè)計(jì)模式中，“實(shí)現(xiàn)一個(gè)接口”泛指“實(shí)現(xiàn)某個(gè)超類型(類/接口)的某個(gè)方法”。

心得

給我的感覺(jué)，簡(jiǎn)單工廠模式更像是一種編程的習(xí)慣。最簡(jiǎn)單的解耦，使得工廠類能夠被各種廠牌反復(fù)使用。
在我還沒(méi)認(rèn)識(shí)簡(jiǎn)單工廠之前，其實(shí)我就寫(xiě)過(guò)很多簡(jiǎn)單工廠的例子了。各種基類BaseActivity、BaseFragment等等通常都會(huì)用到簡(jiǎn)單工廠模式。
優(yōu)點(diǎn): 簡(jiǎn)單，解耦。
缺點(diǎn): 靜態(tài)工廠無(wú)法繼承，違反開(kāi)閉原則。

工廠方法模式

定義

工廠方法模式定義了一個(gè)創(chuàng)建對(duì)象的接口，但由子類決定要實(shí)例化的類是哪一個(gè)。工廠方法讓類把實(shí)例化推遲到子類。

類圖

工廠方法模式有四個(gè)核心類：

Product（產(chǎn)品類）：所有產(chǎn)品必須實(shí)現(xiàn)這個(gè)共同的接口，這樣使用這些產(chǎn)品的類就可以引用這個(gè)接口，而不是具體類。

ConcreteProduct（具體產(chǎn)品類）

Creator（創(chuàng)建者類）：實(shí)現(xiàn)了所有操縱產(chǎn)品的方法，但不實(shí)現(xiàn)工廠方法。

ConcreteCreator（具體創(chuàng)建者類）：實(shí)現(xiàn)了factoryMethod()，負(fù)責(zé)創(chuàng)建一個(gè)或多個(gè)具體產(chǎn)品，只有ConcreteCreator類知道如何創(chuàng)建這些產(chǎn)品。

來(lái)擼代碼

剛剛我們已經(jīng)創(chuàng)建了兩個(gè)類，MusicLabel和SongFactory，MusicLabel在工廠方法中可以作為一個(gè)Creator。SongFactory不在四大核心之內(nèi)，先不管。
我們先來(lái)創(chuàng)造一下產(chǎn)品類和創(chuàng)建者類（他們是兩個(gè)平行類層級(jí)）。

public abstract class MusicLabel {Song createSong(String type){Song song = null;song = orderSong(type);song.prepare();song.Sing();song.Cut();song.Mix();return song;}abstract Song orderSong(String type); //工廠方法 } 復(fù)制代碼public abstract class Song {String singer;//演唱者String lyricist;//作詞人String composer;//作曲人String prepare() {return "演唱者："+singer + ",作詞人："+lyricist + ",作曲人："+composer;}String Sing(){return "錄歌";}String Cut(){return "剪切";}String Mix(){return "混音";} } 復(fù)制代碼

接下來(lái)創(chuàng)建各自的子類。廠牌方面，各位最熟知的可能就是“摩登天空”了，另外，聽(tīng)國(guó)搖的小伙伴對(duì)謝天笑這個(gè)名字應(yīng)該不會(huì)陌生，謝天笑是在“十三月”音樂(lè)廠牌。這里我們就以這兩個(gè)廠牌為例，來(lái)寫(xiě)各自的子類。

摩登天空音樂(lè)廠牌

public class MDSkyMusicLabel extends MusicLabel {@OverrideSong orderSong(String type) { //此處可用簡(jiǎn)單工廠模式if(type.equals("folk")){return new MDSkyFolkSong();}else if(type.equals("rock")){return new MDSkyRockSong();}else if(type.equals("pop")){return new MDSkyPopSong();}else return null;} } 復(fù)制代碼

十三月音樂(lè)廠牌

public class ThirteenMonthMusicLabel extends MusicLabel {@OverrideSong orderSong(String type) { //此處可用簡(jiǎn)單工廠模式if(type.equals("folk")){return new ThirteenMonthFolkSong();}else if(type.equals("rock")){return new ThirteenMonthRockSong();}else if(type.equals("pop")){return new ThirteenMonthPopSong();}else return null;} } 復(fù)制代碼

在MusicLabel類的createSong()中，并不知道真正創(chuàng)建的是哪一個(gè)廠牌的音樂(lè)。創(chuàng)建具體對(duì)象的工作，都在子類中。
接下來(lái)的工作就是把剛剛寫(xiě)過(guò)的MDSkyFolkSong等具體子類繼承Song。這里只寫(xiě)一個(gè)。

public class MDSkyFolkSong extends Song {public MDSkyFolkSong() {singer = "摩登天空的民謠藝人";lyricist = "摩登天空的民謠作詞人";composer = "摩登天空的民謠作曲人";} } 復(fù)制代碼

在這里或許許多小伙伴要說(shuō)這樣寫(xiě)會(huì)有很多子類，很麻煩。但這樣已經(jīng)是最優(yōu)的選擇了。耦合度低，遵守了開(kāi)閉原則。

感受

工廠方法模式有點(diǎn)像簡(jiǎn)單工廠的合集，特別是當(dāng)只有一個(gè)具體工廠類存在時(shí)。
簡(jiǎn)單工廠可以將對(duì)象的創(chuàng)建封裝起來(lái)，但是簡(jiǎn)單工廠不具備工廠方法的彈性，因?yàn)楹?jiǎn)單工廠不能變更正在創(chuàng)建的產(chǎn)品。
優(yōu)點(diǎn): 在簡(jiǎn)單工廠的優(yōu)點(diǎn)上加上“可以變更正在創(chuàng)建的產(chǎn)品”。
缺點(diǎn): 子類相當(dāng)多，不便于管理。

抽象工廠模式

剛剛我們?cè)賹?xiě)具體廠牌的時(shí)候，有提到，可以在具體廠牌類中使用簡(jiǎn)單工廠模式。也就是說(shuō)，我們可以創(chuàng)建MDSkySongFactory和ThirteenMonthSongFactory兩個(gè)工廠類。并且這兩個(gè)工廠做的事都是一樣的，只是具體東西不一樣而已。
那……
我們是不是可以寫(xiě)一個(gè)工廠超類，把要做的事情寫(xiě)成抽象方法，再讓子工廠類各自實(shí)現(xiàn)呢？
可以的！這就是傳說(shuō)中的抽象工廠模式。

定義

為創(chuàng)建一組相關(guān)或相互依賴的對(duì)象提供一個(gè)接口，而且無(wú)需指定他們的具體類。

類圖

Cilent（客戶類）：代碼中只需涉及抽象工廠，運(yùn)行時(shí)自動(dòng)使用實(shí)際的工廠。

AbstractFactory（抽象工廠）：定義了一個(gè)接口，所有具體工廠必須實(shí)現(xiàn)它。這個(gè)接口包含了一組方法來(lái)生產(chǎn)產(chǎn)品。

ConcreteFactory（具體工廠）：客戶只需要使用其中一個(gè)工廠而不需要實(shí)例化任何產(chǎn)品對(duì)象。

AbstractProduct（抽象產(chǎn)品類）：這些抽象產(chǎn)品類就是抽象工廠中所需要的每一個(gè)條件。

ConcreteProduct（具體產(chǎn)品類）：繼承抽象產(chǎn)品類。

由入門(mén)到放棄

剛剛我們說(shuō)過(guò)，我們可以整理一個(gè)工廠超類，這個(gè)工廠超類，就是AbstractFactory！它在我們這個(gè)例子中的作用就是返回一個(gè)singer，一個(gè)lyricist和一個(gè)composer。所以我們可以這樣寫(xiě)。

public interface SongFactory {public String findSinger();public String findLyricist();public String findComposer(); } 復(fù)制代碼

然后給每個(gè)廠牌都寫(xiě)一個(gè)具體工廠

public class MDskySongFactory implements SongFactory {@Overridepublic String findSinger() {return new MDskySinger();}@Overridepublic String findLyricist() {return new MDskyLyricist();}@Overridepublic String findComposer() {return new MDskyComposer();} } 復(fù)制代碼public class ThirteenMonthSongFactory implements SongFactory {@Overridepublic String findSinger() {return new ThirteenMonthSinger();}@Overridepublic String findLyricist() {return new ThirteenMonthLyricist();}@Overridepublic String findComposer() {return new ThirteenMonthComposer();} } 復(fù)制代碼

還需要重寫(xiě)一下Song類

public abstract class Song {String singer;//演唱者String lyricist;//作詞人String composer;//作曲人abstract void prepare();//只改變了這個(gè)方法String Sing(){return "錄歌";}String Cut(){return "剪切";}String Mix(){return "混音";}@Overridepublic String toString() {return "Song{" +"singer='" + singer + '\'' +", lyricist='" + lyricist + '\'' +", composer='" + composer + '\'' +'}';} } 復(fù)制代碼

現(xiàn)在就可以根據(jù)工廠類來(lái)寫(xiě)歌曲子類了。每個(gè)廠牌都有FolkSong、RockSong、PopSong，現(xiàn)在不用寫(xiě)那么多子類，只需要建立一個(gè)相應(yīng)子類，材料（作詞作曲演唱）就交給傳遞進(jìn)去的工廠類來(lái)解決！

public class FolkSong extends Song{SongFactory factory;public FolkSong(SongFactory factory) {this.factory = factory;}@Overridevoid prepare() {singer = factory.findSinger();lyricist = factory.findLyricist();composer = factory.findComposer();} } 復(fù)制代碼

現(xiàn)在我們幾乎完成了所有的材料，就差調(diào)用了?，F(xiàn)在先來(lái)理一理這些東西。

抽象工廠類是SongFactor。

具體工廠類是MDskySongFactory 和ThirteenMonthSongFactory。

抽象產(chǎn)品類是Singer、Lyricist、Composer。

具體產(chǎn)品類是MDskySinger、ThirteenMonthSinger等。

Client是MDSkyMusicLabel和ThirteenMonthMusicLabel。

現(xiàn)在就在Client里面調(diào)用看看吧。

public class MDSkyMusicLabel extends MusicLabel {@OverrideSong orderSong(String type) {Song song = null;SongFactory factory = new MDskySongFactory();if(type.equals("folk")){song = new FolkSong(factory);}else if(type.equals("rock")){song = new RockSong(factory);}else if(type.equals("pop")){song = new PopSong(factory);}return song;} } 復(fù)制代碼

完美！到處都充斥著依賴倒置的清香。

體會(huì)

這個(gè)模式雖然需要些的核心類比較多，但是當(dāng)需求滿足“為相互依賴的對(duì)象提供一個(gè)接口”，具體對(duì)象又比較多，又易修改的時(shí)候，這個(gè)模式的優(yōu)點(diǎn)你就能體會(huì)到了。
優(yōu)點(diǎn): 閉合開(kāi)閉原則，耦合低。
缺點(diǎn): 不適用于對(duì)象數(shù)量少的情況。

BitmapFactory

BitmapFactory是android中比較常見(jiàn)的工廠模式的使用。我們肯定都寫(xiě)過(guò)這樣一句代碼

Bitmap bitmap = BitmapFactory.decodeResource(getResources(), R.drawable.ic_launcher) ; 復(fù)制代碼

看出來(lái)什么沒(méi)？？
這特么就是個(gè)簡(jiǎn)單工廠模式啊！還是個(gè)靜態(tài)工廠！
為何這么說(shuō)，因?yàn)樗峭ㄟ^(guò)類名調(diào)用方法，并且返回了一個(gè)對(duì)象。這不就是簡(jiǎn)單工廠嗎？

看里面，全是紅彤彤的靜態(tài)方法。這個(gè)工廠做的事就是通過(guò)不同的參數(shù)，返回Bitmap對(duì)象。這也就是簡(jiǎn)單工廠模式的作用。
今天的源碼解讀就到此為止了，要問(wèn)我為啥沒(méi)寫(xiě)擴(kuò)展。
你要是看懂了工廠模式，就不會(huì)問(wèn)這個(gè)問(wèn)題。

為什么要用工廠模式

（此處應(yīng)有彈幕：“收尾呼應(yīng)，滿分作文！”）
我寫(xiě)的優(yōu)點(diǎn)里面那么多，還不能讓你使用工廠模式嗎？
就沖解耦合這一點(diǎn)，你就該用它！

總結(jié)

以下是我“設(shè)計(jì)模式系列”文章，歡迎大家關(guān)注留言投幣丟香蕉。

設(shè)計(jì)模式入門(mén)
Java與Kotlin的單例模式
Kotlin的裝飾者模式與源碼擴(kuò)展
由淺到深了解工廠模式

總結(jié)

以上是生活随笔為你收集整理的由浅到深了解工厂模式的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。