項目實戰(應用市場)----FragmentFactory

import android.support.v4.app.Fragment;

import java.util.HashMap;
import java.util.Map;

/**
 * Created by zlr on 2014/7/19.
 */
public class FragmentFactory {
	public static final int TAB_HOME = 0;
	public static final int TAB_APP = 1;
	public static final int TAB_GAME = 2;
	public static final int TAB_SUBJECT = 3;
	public static final int TAB_RECOMMEND = 4;
	public static final int TAB_CATEGORY = 5;
	public static final int TAB_TOP = 6;

	private static Map<Integer, BaseFragment> mFragmentCache = new HashMap<Integer, BaseFragment>();

	public static Fragment createFragment(int position) {

		BaseFragment fragment = mFragmentCache.get(position);
		if (fragment != null) {
			return fragment;
		}
		switch (position) {
			case TAB_HOME:
				fragment = new HomeFragment();
				break;
			case TAB_APP:
				fragment = new AppFragment();
				break;
			case TAB_GAME:
				fragment = new GameFragment();
				break;
			case TAB_SUBJECT:
				fragment = new SubjectFragment();
				break;
			case TAB_RECOMMEND:
				fragment = new RecommendFragment();
				break;
			case TAB_CATEGORY:
				fragment = new CategoryFragment();
				break;
			case TAB_TOP:
				fragment = new TopFragment();
				break;
		}
		mFragmentCache.put(position, fragment);
		return fragment;
	}
}

簡單工廠模式

簡單工廠模式又稱靜態工廠方法模式。重命名上就可以看出這個模式一定很簡單。它存在的目的很簡單：定義一個用於創建對象的接口。 

      先來看看它的組成： 
         1) 工廠類角色：這是本模式的核心，含有一定的商業邏輯和判斷邏輯。
         2) 抽象產品角色：它一般是具體產品繼承的父類或者實現的接口。         

         3) 具體產品角色：工廠類所創建的對象就是此角色的實例。在java中由一個具體類實現。 

工廠方法模式

       工廠方法模式去掉了簡單工廠模式中工廠方法的靜態屬性，使得它可以被子類繼承。這樣在簡單工廠模式裏集中在工廠方法上的壓力可以由工廠方法模式裏不同的工廠子類來分擔。 

工廠方法模式組成：

1)抽象工廠角色： 這是工廠方法模式的核心，它與應用程序無關。是具體工廠角色必須實現的接口或者必須繼承的父類。在java中它由抽象類或者接口來實現。 
       2)具體工廠角色：它含有和具體業務邏輯有關的代碼。由應用程序調用以創建對應的具體產品的對象。 
       3)抽象產品角色：它是具體產品繼承的父類或者是實現的接口。在java中一般有抽象類或者接口來實現。 
       4)具體產品角色：具體工廠角色所創建的對象就是此角色的實例。在java中由具體的類來實現。

缺點： 可以看出工廠方法的加入，使得對象的數量成倍增長。當產品種類非常多時，會出現大量的與之對應的工廠對象，這不是我們所希望的。因爲如果不能避免這種情 況，可以考慮使用簡單工廠模式與工廠方法模式相結合的方式來減少工廠類：即對於產品樹上類似的種類（一般是樹的葉子中互爲兄弟的）使用簡單工廠模式來實 現。

工廠方法小結： 

        工廠方法模式彷彿已經很完美的對對象的創建進行了包裝，使得客戶程序中僅僅處理抽象產品角色提供的接口。那我們是否一定要在代碼中遍佈工廠呢？大可不必。也許在下面情況下你可以考慮使用工廠方法模式： 
     1)當客戶程序不需要知道要使用對象的創建過程。 
     2)客戶程序使用的對象存在變動的可能，或者根本就不知道使用哪一個具體的對象。

優化簡單工廠模式：

簡單工廠模式與工廠方法模式真正的避免了代碼的改動了？沒有。在簡單工廠模式中，新產品的加入要修改工廠角色中的判斷語句；而在工廠方法模式中，要麼將判 斷邏輯留在抽象工廠角色中，要麼在客戶程序中將具體工廠角色寫死（就象上面的例子一樣）。而且產品對象創建條件的改變必然會引起工廠角色的修改。
       面對這種情況，我們可以使用反射機制：

抽象工廠模式 

隨着客戶的要求越來越高，寶馬車需要配置空調。於是這個工廠開始生產寶馬車和配置需要的空調。這時候工廠有二個系列的產品:寶馬車和空調.寶馬車必須使用對應的空調才能使用.這時候分別使用一個車工廠和一個空調工廠都不能滿足我們的需求,我們必須確認車跟空調的對應關係。因此把車工廠跟空調工廠聯繫在一起。因此出現了抽象工廠模式。
     可以說，抽象工廠模式和工廠方法模式的區別就在於需要創建對象的複雜程度上。而且抽象工廠模式是三個裏面最爲抽象、最具一般性的。 
抽象工廠模式的用意爲：給客戶端提供一個接口，可以創建多個產品族中的產品對象 ，而且使用抽象工廠模式還要滿足一下條件：
     1)系統中有多個產品族，而系統一次只可能消費其中一族產品。 
     2)同屬於同一個產品族的產品以其使用。 

抽象工廠模式的各個角色（和工廠方法一樣）： 
     1)抽象工廠角色： 這是工廠方法模式的核心，它與應用程序無關。是具體工廠角色必須實現的接口或者必須繼承的父類。在java中它由抽象類或者接口來實現。 
     2)具體工廠角色：它含有和具體業務邏輯有關的代碼。由應用程序調用以創建對應的具體產品的對象。
     3)抽象產品角色：它是具體產品繼承的父類或者是實現的接口。
     4)具體產品角色：具體工廠角色所創建的對象就是此角色的實例。