工廠方法模式的做用就是封裝對象的建立,由子類決定要建立的對象是什麼。java
工廠方法模式特別適合與須要建立複雜對象的場景android
首先能夠看一下,工廠方法模式的UML類圖 設計模式
這樣一個圖看起來可能有點暈,下面就結合時下最流行的共享單車,寫一個工廠方法模式的通用模式代碼。app
/** * 抽象單車產品 *簡單起見,單車的製造方式(外觀)和計費方式 做爲單車類的兩個方法 */
public interface Bicycle {
/** * 單車生產方式 */
String manufacture();
/** * 單車計費方式 */
String billing();
}
/** * Bicycle 抽象單車生產工廠 */
public interface BicycleFactory {
Bicycle makeBicycle();
}
public class Mobike implements Bicycle {
@Override
public String manufacture() {
System.out.print("摩拜單車---橙色---有定位功能");
return "摩拜單車---橙色---有定位功能";
}
@Override
public String billing() {
System.out.print("Mobike每30分鐘收費1元");
return "Mobike每30分鐘收費1元";
}
}
public class MobikeFactory implements BicycleFactory {
@Override
public Bicycle makeBicycle() {
return new Mobike();
}
}
public class Ofo implements Bicycle {
@Override
public String manufacture() {
System.out.print("ofo單車---黃色---密碼不變");
return "ofo單車---黃色---密碼不變";
}
@Override
public String billing() {
System.out.print("ofo單車: 師生認證用戶0.5元/小時,非師生用戶1元/小時");
return "ofo單車: 師生認證用戶0.5元/小時,非師生用戶1元/小時";
}
}
public class OfoFactory implements BicycleFactory {
@Override
public Bicycle makeBicycle() {
return new Ofo();
}
}複製代碼
在上面的代碼中:ide
這就是工廠模式。全部的產品(Mobike和Ofo)有共同的父類 Bicycle,而每個產品又有各自的工廠(MobikeFactory和
OfoFactory)去負責建立本身;固然這裏全部的產品能夠有公共的工廠,在公共的工廠裏經過參數負責生成不一樣的產品。以下方式:post
/** * 全部產品共用一個工廠 */
public class CommonFactory {
public static Bicycle makeBicycle(String type) {
switch (type) {
case "mobike":
return new Mobike();
case "ofo":
return new Ofo();
default:
return null;
}
}
}複製代碼
我的感受,每一個產品使用各自的工廠是一種更有設計模式的作法,也就是更符合開閉原則;若是有了新產品,就沒必要去修改原有的工廠,增長新的產品和工廠便可。ui
有個工廠,就很是方便咱們去建立不一樣的對象了。this
public class FactoryPatternActivity extends AppCompatActivity {
private TextView bike_result;
private BicycleFactory factory;
private Bicycle mBicycle;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_factory_pattern);
bike_result = V.f(this, R.id.bike_result);
}
public void MobikeClick(View view) {
factory = new MobikeFactory();
mBicycle = factory.makeBicycle();
updateView(mBicycle);
}
public void OfoClick(View view) {
factory = new OfoFactory();
mBicycle = factory.makeBicycle();
updateView(mBicycle);
}
private void updateView(Bicycle mBicycle) {
bike_result.setText("");
StringBuilder sb = new StringBuilder();
sb.append(mBicycle.manufacture())
.append("\n")
.append(mBicycle.billing());
bike_result.setText(sb.toString());
}
}複製代碼
在這裏使用工廠模式,BicycleFactory 封裝了Bicycle 對象具體生成的過程;當須要具體的對象時,調用每一個對象各自的工廠生成對象便可。試想,若是沒有使用工廠模式,那麼這裏FactoryPatternActivity 將包含大量的代碼去負責建立複雜的Bicycle對象,可是從MVP的角度來講,這是徹底不屬於Activity(View)的工做。spa
在Android 系統中,說道Factory你們第一個想到的可能就是BitmapFactory了。研究過Bitmap的同窗應該清楚,BitmapFactory 爲了方便開發者,提供了一系列的方法方便你們經過各類途徑建立Bitmap。設計
這裏能夠看一下decodeStream(InputStream is) 方法:
public static Bitmap decodeStream(InputStream is) {
return decodeStream(is, null, null);
}複製代碼
能夠看到,這裏又會去調用別的方法;最終上述的全部方法,異曲同工都會調用到一些native的方法去真正的完成Bitmap的建立。其實按照上面的UML圖來講,嚴格來講BitmapFactory 的實現並非工廠方法模式;只能說是簡單工廠。在BitmapFactory類中對於惟一的產品Bitmap只有惟一的工廠BitmapFactory,它全部的生產方法都是靜態的;若是要新增一種生產Bitmap的方式,就得修改惟一的工廠(BitmapFactory)。所以,從設計模式的角度來講,徹底不符合開閉原則。
這裏並非說BitmapFactory這個類的寫法很差,只是恰好從工廠方法模式的角度找了一個你們熟悉的類作了一個分析,Android系統的代碼其實寫的很好。BitmapFactory 這個類裏包含的方法已經夠你們使用,所以它設計成這個樣子是徹底合理的。
《Android 源碼設計模式解析於實戰》這本書中提到 onCreate 方法是的實現能夠說是工廠模式,的確從廣義角度來講,經過不一樣的參數(R.layout.acitity) 建立出了不一樣的View;的確是能夠算是工廠模式。至於具體代碼的實現邏輯,這裏就不拾人牙慧了。
總的來講,工廠模式就是種瓜得瓜,種豆得豆;根據不一樣的輸入建立不一樣類型的對象。經過上面的實例其實能夠總結出規律,當咱們在代碼中寫了不少if-else或者是switch時,是否是能夠考慮如下使用工廠模式,也許咱們就是在建立不經過的對象,也許只是本身沒有發現。
工廠方法模式真的感受只能意會,不能言傳。看別人寫的東西老是忘掉,這樣本身寫一遍纔算理解了。