方法工厂模式

在简单工厂模式中我们发现一个问题就是我们的工厂是比较死的，如果我们新增一个产品，就需要改变工厂模式的判断条件

很明显这是不符合我们要求的。

方法工厂模式中我们有四种角色： 抽象产品 具体产品 抽象工厂 具体工厂

我们产品是产品 工厂是工厂 我们一个产品对应一个具体工厂  。

详细见下面代码：

//抽象产品 
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和反射区指定具体的实现方式