Android設計模式之工廠模式

定義

工廠模式是咱們最經常使用的實例化對象模式了，是用工廠方法代替new操做的一種模式。著名的Jive論壇 ,就大量使用了工廠模式，工廠模式在Java程序系統能夠說是隨處可見。由於工廠模式就至關於建立實例對象的new，咱們常常要根據類Class生成實例 對象，如A a=new A() 工廠模式也是用來建立實例對象的，因此之後new時就要多個心眼，是否能夠考慮使用工廠模式，雖然這樣作，可能多作一些工做，但會給你係統帶來更大的可擴 展性和儘可能少的修改量。

我的理解：工廠模式就等於生產產品，工廠模式實例化對象，當你須要實例化一個對象，你發現不止一個選擇（全部供選擇的類都實現了同一個接口）的時候，針對這一狀況寫一個通用的方法（方法返回類型是那個共用的接口），這就是工廠模式了。

案例講解：以兩個工廠造車類和全部工廠操做類來實現工廠模式

寶馬類

public class Bmw implements Volkswagen {
    
     public static final int ID = 1;
    @Override
    public void drive() {
        // TODO Auto-generated method stub
        System.out.println("寶馬造車成功啦");  
    }

    @Override
    public String getName() {
        // TODO Auto-generated method stub
        return "寶馬";
    }

}

奔馳類

public class Benz implements Volkswagen {
    public static final int ID = 0;
    
    @Override
    public void drive() {
        // TODO Auto-generated method stub
        System.out.println("奔馳造車成功了");  

    }

    @Override
    public String getName() {
        // TODO Auto-generated method stub
        return "奔馳";
    }

}

Volkswagen.Java

/***
 * 產品操做
 * @author zq
 *
 */
public interface Volkswagen {

    void drive();
    
    String getName();
}

工廠類

/***
 * 工廠類
 * @author zq
 *
 */
public class VehicleVolkswagenFactory {
    
    
    public Volkswagen createVolkswagen(int id)
    {
        Volkswagen volkswagen=null;
        switch (id) {
        case Benz.ID:
            volkswagen=new Benz();
            break;
        case Bmw.ID:
            volkswagen=new Bmw();
            break;

        default:
            break;
        }
        return volkswagen;
    }
       //反射獲得
    public Volkswagen createVolkswagen(Class <? extends Volkswagen> clazz){
        Volkswagen volkswagen = null;
        try {
            volkswagen = clazz.newInstance();
        } catch (InstantiationException e) {
            e.printStackTrace();
        } catch (IllegalAccessException e) {
            e.printStackTrace();
        }
        return volkswagen;
    }

}

 

Activity.Java

public class VehicleActivity extends Activity
{
    TextView tv_benz,tv_bmx;
        VehicleVolkswagenFactory factory;
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        // TODO Auto-generated method stub
        super.onCreate(savedInstanceState);
        setContentView(R.layout.vehicle_activity);
        factory = new VehicleVolkswagenFactory();
        initViewBenz();
        initViewBmw();
    }
    private void initViewBenz() {
        // TODO Auto-generated method stub
         tv_benz=(TextView) findViewById(R.id.tv_benz);
         Volkswagen volkswagen=factory.createVolkswagen(Benz.ID);
         tv_benz.setText(volkswagen.getName());
         volkswagen.drive();//工廠相關方法
        
    }
    private void initViewBmw() {
        // TODO Auto-generated method stub
        tv_bmx=(TextView) findViewById(R.id.tv_bmx);
        Volkswagen volkswagen=factory.createVolkswagen(Bmw.class);
        tv_bmx.setText("反射獲得"+volkswagen.getName());
        
    }
    
}

優勢
工廠類是整個模式的關鍵.包含了必要的邏輯判斷,根據外界給定 的信息,決定究竟應該建立哪一個具體類的對象.經過使用工廠類,外界能夠從直接建立具體產品對象的尷尬局面擺脫出來,僅僅須要負責「消費」對象就能夠了。而 沒必要管這些對象究竟如何建立及如何組織的．明確了各自的職責和權利，有利於整個軟件體系結構的優化。

缺點
因爲工廠類集中了全部實例的建立邏輯，違反了高內聚責任分配原則，將所有建立邏輯集中到了一個工廠類中；它所能建立的類只能是事先考慮到的，若是須要添加新的類，則就須要改變工廠類了。
當系統中的具體產品類不斷增多時候，可能會出現要求工廠類根據不一樣條件建立不一樣實例的需求．這種對條件的判斷和對具體產品類型的判斷交錯在一塊兒，很難避免模塊功能的蔓延，對系統的維護和擴展很是不利；