GOF23种设计模式之工厂模式

工厂模式

工厂模式：
实现了创建者和调用者的分离。
详细分类：

• 简单工厂模式
• 工厂方法模式
• 抽象工厂模式

面向对象设计的基本原则：

1. 单一职责原则 ：应该有且只有一个原因引起类的变化
2. 里氏替换原则 ：只要父类能出现的地方，其子类就应该能出现。也就是用子类替换父类后，保证程序照样运行
3. DIP 依赖倒转原则 DependenceInversionPrinciple：要针对接口编程，不要针对实现编程。
4. 接口隔离原则 ：接口细化，也就是接口中的方法要尽量少
5. LoD 迪米特法则 LawofDemeter：只与你直接的朋友通信，而避免和陌生人通信。
6. OCP 开闭原则 Open-ClosedPrinciple ：一个软件的实体应当对扩展开放，对修改关闭。

工厂模式的核心本质：

实例化对象，用工厂方法代替new操作。

将选择实现类、创建对象统一管理和控制。从而将调用者跟我们的实现类解耦。

简单工厂模式

假设有Car接口：

package com.xyj.factory.factorymethod;

public interface Car {
	void run();
}

及其两个实现类：

package com.xyj.factory.factorymethod;

public class Ford implements Car{

	@Override
	public void run() {
		System.out.println("福特正在行驶!");
	}

}

package com.xyj.factory.simplefactory;

public class Honda implements Car{

	@Override
	public void run() {
		System.out.println("本田正在行驶!");
	}

}

假设没有简单工厂的话，我们是怎么创建对象的：

package com.xyj.factory.simplefactory;

/**
 * 测试在没有工厂模式的情况下
 * @author Administrator
 *
 */
public class Client01 {
	public static void main(String[] args) {
		Car c1=new Ford();
		Car c2=new Honda();
		
		c1.run();
		c2.run();
	}
	
}

加入简单工厂：

package com.xyj.factory.simplefactory;

/**
 * 简单工厂模式
 * @author Administrator
 *
 */
public class CarFactory {
	
	public static Car createCar(String brand) {//违反了开闭原则
		if("福特".equals(brand)) {
			return new Ford();
		}else if("本田".equals(brand)) {
			return new Honda();
		}else {
			return null;
		}
	}
	
}

或者简单工厂可以这么写：

package com.xyj.factory.simplefactory;

/**
 * 简单工厂模式2
 * @author Administrator
 *
 */
public class CarFactory2 {
	
	public static Car createFord(String brand) {
		return new Ford();
	}
	
	public static Car createHonda(String brand) {
		return new Honda();
	}
	
}

有简单工厂的情况下，我们创建对象：

package com.xyj.factory.simplefactory;

public class Client2 {
	
	public static void main(String[] args) {
		Car c1=CarFactory.createCar("福特");
		Car c2=CarFactory.createCar("本田");
		
		c1.run();
		c2.run();
	}
}

这样的话，我们就降低了客户端和其他类之间的依赖关系，现在只需要依赖于简单工厂类和接口类即可。

但是我们发现简单工厂违反了开闭原则(一个软件的实体应当对扩展开放，对修改关闭)，此时我们加入想要扩展类的功能，加入别的车的话就需要修改简单工厂类了，那么有什么别的方法呢——工厂方法模式。

工厂方法模式

Car接口和两个实现类同上面一样，不再展示。

添加了工厂方法的接口：

package com.xyj.factory.factorymethod;

public interface CarFactory {
	Car createCar();
}

以及接口下的两个实现类：

package com.xyj.factory.factorymethod;

public class FordFactory implements CarFactory{

	@Override
	public Car createCar() {
		return new Ford();
	}

}

package com.xyj.factory.factorymethod;

public class HondaFactory implements CarFactory{

	@Override
	public Car createCar() {
		return new Honda();
	}

}

此时再去测试：

package com.xyj.factory.factorymethod;

public class Client {
	public static void main(String[] args) {
		Car c1=new FordFactory().createCar();
		Car c2=new HondaFactory().createCar();
		
		c1.run();
		c2.run();
	}
}

我们发现结果依旧会是一样的，而且我们添加新的功能的时候不再需要修改源代码啦，只需要添加新的类和新的工厂即可。
但是我们也发现了这种方法的弊端：扩展功能多的时候会增加大量的类，造成类结构繁杂。

简单工厂模式和工厂方法模式比较

• 结构复杂度
  从这个角度比较，显然简单工厂模式要占优。简单工厂模式只需一个工厂类，而工厂方法模式的工厂类随着产品类个数增加而增加，这无疑会使类的个数越来越多，从而增加了结构的复杂程度。
• 代码复杂度
  代码复杂度和结构复杂度是一对矛盾，既然简单工厂模式在结构方面相对简洁，那么它在代码方面肯定是比工厂方法模式复杂的了。简单工厂模式的工厂类随着产品类的增加需要增加很多方法（或代码），而工厂方法模式每个具体工厂类只完成单一任务，代码简洁。
• 客户端编程难度
  工厂方法模式虽然在工厂类结构中引入了接口从而满足了OCP，但是在客户端编码中需要对工厂类进行实例化。而简单工厂模式的工厂类是个静态类，在客户端无需实例化，这无疑是个吸引人的优点。
• 管理上的难度
  众所周知，工厂方法模式完全满足OCP，即它有非常良好的扩展性。那是否就说明了简单工厂模式就 没有扩展性呢？答案是否定的。简单工厂模式同样具备良好的扩展性——扩展的时候仅需要修改少量的代码（修改工厂类的代码）就可以满足扩展性的要求了。尽管这没有完全满足OCP，但我们不需要太拘泥于设计理论，要知道，sun提供的java官方工具包中也有想到多没有满足OCP的例子啊。
  然后我们从维护性的角度分析下。假如某个具体产品类需要进行一定的修改，很可能需要修改对应的工厂类。当同时需要修改多个产品类的时候，对工厂类的修改会变得相当麻烦（对号入座已经是个问题了）。反而简单工厂没有这些麻烦，当多个产品类需要修改是，简单工厂模式仍然仅仅需要修改唯一的工厂类（无论怎样都能改到满足要求吧？大不了把这个类重写）。

根据设计理论建议：工厂方法模式。但实际上，我们一般都用简单工厂模式。