方法工廠模式

在簡單工廠模式中咱們發現一個問題就是咱們的工廠是比較死的，若是咱們新增一個產品，就須要改變工廠模式的判斷條件

很明顯這是不符合咱們要求的。

方法工廠模式中咱們有四種角色： 抽象產品 具體產品 抽象工廠 具體工廠

咱們產品是產品 工廠是工廠 咱們一個產品對應一個具體工廠  。

    詳細見下面代碼：

//抽象產品 
public interface Color {
	public void showColor();
}
//具體產品1
public class RedColor implements Color {
	@Override
	public void showColor() {
		System.err.println("show red");
	}
}

//具體產品2
public class RedColor implements Color {
	@Override
	public void showColor() {
		System.err.println("show yelow");
	}
}

//抽象工廠

public interface ColorFactory {

	public Color newInstance();

}

//工廠實現：
public class RedColorFactory implements ColorFactory {
	
	@Override
	public Color newInstance() {
		return new RedColor();
	}
}

//工廠實現

public class YellowColorFactory implements ColorFactory {

	@Override
	public Color newInstance() {
		return new YellowColor();
	}
}


這樣調用就能夠實現：
               ColorFactory colorFactory = new RedColorFactory();
		Color redColor = colorFactory.newInstance();
		redColor.showColor();

		ColorFactory factory2 = new YellowColorFactory();
		Color yellowColor = factory2.newInstance();
		yellowColor.showColor();

以上代碼就能夠避免簡單工廠的問題

假設咱們須要一個BluColor 就新增一個BlurColor的實現類，一個BlueColorFactory的實現類

對原有的代碼沒有任何修改的地方

ColorFactory factory3 = new BlueColorFactory();
Color blueColor = factory3.newInstance();
blueColor.showColor();

靈活使用

缺點：

• 在添加新產品時，須要編寫新的具體產品類，並且還要提供與之對應的具體工廠類，系統中類的個數將成對增長，在必定程度上增長了系統的複雜度，有更多的類須要編譯和運行，會給系統帶來一些額外的開銷。

本身註解： 咱們增長了一個blueColor就得增長一個產品實現一個工廠實現 成對增長

• 因爲考慮到系統的可擴展性，須要引入抽象層，在客戶端代碼中均使用抽象層進行定義，增長了系統的抽象性和理解難度，且在實現時可能須要用到DOM、反射等技術，增長了系統的實現難度。

本身註解： 日誌記錄 針對日誌記錄的方式是數據庫 文件 這些均可以放在配置文件中間利用反射區構建

一個日誌記錄的抽象類  2個日誌記錄的具體實現類 分別是文件和數據庫 

這些均可以放在配置文件中利用DOM和反射區指定具體的實現方式