不少時候咱們編寫了好幾個接口的實現類,這些實現類分別有不一樣特性,用在不一樣的情景下。而咱們對於這些實現類,也每每不會對外暴露內部增長的方法,只但願外部調用接口的方法,在這種狀況下,咱們不必讓調用者知道實現類,只須要提供一個方法讓調用者使用從而建立具備不一樣特性的接口實例。而這個方法咱們一般寫在一個叫工廠類的類裏面,從而對應這個接口,這樣調用者能夠根據自身須要選擇具備不一樣特性的接口實例,又避免了實現類和外部調用者耦合的問題。設計模式
工廠模式屬於建立型的設計模式(用於建立對象),由工廠對象提供方法建立接口的實例。服務器
在工廠模式中,建立對象時不會對外暴露建立邏輯,即外部不知道建立出來的實際類型是什麼。url
一個子接口對應一個工廠類(一個接口伴隨一個工廠類),能夠概括爲一對一關係。spa
只提供接口實例給外部使用,並且外部只能使用接口的方法,不然工廠模式不適合。設計
有一個需求,須要向外部提供一個日誌打印器,根據不一樣狀況,能夠在服務器打印,本地打印,控制檯打印日誌。日誌
這裏咱們先定義一個接口Logger:code
public interface Logger{ public void log(String text); }
根據上面所說的,也有一個工廠類對應:server
public Logger getLogger(String type){ if(type.equals("server")){ return new ServerLogger(); }else if(type.equals("file")){ return new FileLogger(); }else if(type.equals("local")){ return new LocalLogger(); } return null; }
在Android開發中,一般咱們都會有圖片上傳的需求。曾經有次經歷過這樣的需求,圖片上傳到服務器中而後返回圖片路徑(用於後面的接口做爲其中一個Post參數),後來業務變動了,接入第三方圖片上傳存儲服務,也是調用SDK上傳圖片返回圖片路徑。對象
這個時候就很合適使用工廠模式來適應這種業務變動,首先定義一個圖片上傳接口,經過工廠類得到不一樣的圖片上傳對象。這樣若是之後圖片上傳業務再次變動,那麼只須要在工廠類內部增長建立新實例的邏輯,外部只須要修改建立實例的方法的傳入參數。blog
代碼場景:
// 原來代碼 PicInterface pic = PicFacetory.getPic("OriginServer"); // 新代碼 PicInterface pic = PicFacetory.getPic("ThirdPartSDK"); // 上傳,upload方法是實現接口的方法 String url = pic.upload(fileObj);