坚持就是胜利,打卡第二篇
本次学习基于Java语言
- 【工厂模式】属于【创建者模式】的一种,现实中工厂生产产品,设计模式中工厂生产对象。如果我们需要使用某类型的对象时,直接new 构造器获得该对象,就会对该对象产生严重的耦合,再比如想要更换对象,就需要去修改代码中new对象的所有地方,违背开闭原则。而使用工厂生产对象,我们只需要与工厂进行交互,修改的时候只需要改工厂代码就可以,达到了与对象解耦合的目的。所以,工厂模式最大的好处就是解除耦合
先来看一个点咖啡案例的源码
/**
* 抽象产品咖啡类,描述具体产品的共性行为
*/
public abstract class AbstractCoffee {
public abstract String getName();
}
/**
* 具体产品咖啡类:美式咖啡
*/
public class AmericanCoffee extends AbstractCoffee {
@Override
public String getName() {
return "美式咖啡";
}
}
/**
* 具体产品咖啡类:拿铁咖啡
*/
public class LatteCoffee extends AbstractCoffee {
@Override
public String getName() {
return "拿铁咖啡";
}
}
/**
* 咖啡店类,负责生产具体咖啡
*/
public class CoffeeStore {
/**
* 生产咖啡的方法
*
* @param coffeeType 调用方法的时候需要传入咖啡类型
* @return AbstractCoffee
*/
public AbstractCoffee orderCoffee(String coffeeType) {
AbstractCoffee coffee = null;
if ("latte".equalsIgnoreCase(coffeeType)) {
// 生产拿铁咖啡
coffee = new LatteCoffee();
} else if ("american".equalsIgnoreCase(coffeeType)) {
// 生产美式咖啡
coffee = new AmericanCoffee();
} else {
throw new RuntimeException("抱歉,本店没有该类咖啡");
}
return coffee;
}
}
可以看出这时的咖啡店类就只能卖两种咖啡,Latte和American,如果想要其他类型的咖啡,就不得不修改CoffeeStore类的源代码,在orderCoffee()方法体中增加一个判断并创建其他具体的咖啡类对象,咖啡店类与具体咖啡对象产生了严重耦合,不符合开闭原则
简单工厂模式
简单工厂模式并没有收录到GOF 23种设计模式之中,这种实现方法更像是一种良好的编程习惯
简单工厂模式的结构
- 抽象产品类:描述具体产品的共性属性和行为
- 具体产品类:继承抽象产品,实现抽象或扩展功能
- 简单工厂类:负责具体产品的生产
基于以上的例子,我们引入一个简单工厂(也可以使用静态工厂,工厂中的方法使用静态方法即可),将咖啡店中创建对象的逻辑写到简单工厂当中,咖啡店中只依赖抽象咖啡产品,而不涉及具体产品的创建,这时候我们要加新品种的咖啡,就不需要再修改咖啡店类,而是修改工厂类即可,实现了咖啡店类和具体产品对象的解耦合
抽象产品类和具体产品类不需要修改,只添加工厂类,修改咖啡店类即可
/**
* 简单工厂
*/
public class SimpleCoffeeFactory {
public AbstractCoffee createCoffee(String coffeeType){
AbstractCoffee coffee = null;
if ("latte".equalsIgnoreCase(coffeeType)) {
// 生产拿铁咖啡
coffee = new LatteCoffee();
} else if ("american".equalsIgnoreCase(coffeeType)) {
// 生产美式咖啡
coffee = new AmericanCoffee();
} else {
throw new RuntimeException("抱歉,本店没有该类咖啡");
}
return coffee;
}
}
/**
* 咖啡店类,负责调用工厂生产咖啡,不需要依赖具体的咖啡类
*/
public class CoffeeStore {
/**
* 调用工厂生产咖啡的方法
* 不再涉及具体产品的创建,需要什么类型的产品只需要调用工厂获取即可
* @param coffeeType 调用方法的时候需要传入咖啡类型
* @return AbstractCoffee
*/
public AbstractCoffee orderCoffee(String coffeeType) {
return new SimpleCoffeeFactory().createCoffee(coffeeType);
}
}
简单工厂+配置文件
上面我们使用 “简单工厂模式” 解决了咖啡店类和具体产品类的耦合问题。但是,认真观察上面的例子,我们又会发现新问题。我们的简单工厂又彻底的和具体咖啡类完全耦合在一起了,这是拆了东墙补了西墙。这时新的问题是我们怎么样让工厂类和具体产品类断开耦合呢?如果光靠不断增加新的工厂类显然行不通,不管增加多少工厂,最后总有一个工厂需要与具体产品类直接联系。所以我们需要引入与整体的架构没有直接关联的一个东西----配置文件
将工厂代码修改如下:
/**
* 简单工厂+配置文件
* 配置文件存储具体产品类的全限定类名
* 我们只需要根据键值取出存储的类名,利用反射机制生产对象即可
*/
/*
配置文件:bean.properties
内容:
american=com.noah.demo01.AmericanCoffee
latte=com.noah.demo01.LatteCoffee
*/
public class SimpleCoffeeFactory {
public AbstractCoffee createCoffee(String coffeeType){
AbstractCoffee coffee = null;
InputStream is = SimpleCoffeeFactory.class.getClassLoader().getResourceAsStream("bean.properties");
Properties pro = new Properties();
try {
pro.load(is);
String className = pro.getProperty(coffeeType);
Class<?> clazz = Class.forName(className);
Constructor<?> constructor = clazz.getConstructor();
coffee = (AbstractCoffee)constructor.newInstance();
} catch (Exception e) {
e.printStackTrace();
}
return coffee;
}
}
可以看出我们的工厂已经不再与具体产品耦合了,她只依赖于抽象;这时候我们要加不同类型的具体咖啡,只需要编写具体咖啡类,让她继承抽象咖啡类,然后在配置文件中配置相应的类名即可。对于原来已经存在的代码,我们并没有修改,而要扩展新类型咖啡也非常方便;简单工厂+配置文件的实现方式,做到了对修改关闭对扩展开放,她是完全符合开闭原则的。
工厂方法模式
JDK中,单列集合获取迭代器的方法 iterator() 使用到了工厂方法模式
工厂方法模式的结构
- 抽象产品类:描述具体产品的共性属性和行为
- 具体产品类:继承抽象产品,实现抽象或扩展功能
- 抽象工厂类:描述抽象产品的创建,不关心具体产品
- 具体工厂类:实现抽象工厂,实现抽象,负责具体产品的创建
抽象产品类和具体产品类不需要修改,添加抽象工厂类和具体工厂类,修改咖啡店类即可
/**
* 抽象工厂类
*/
public interface CoffeeFactory {
public abstract AbstractCoffee createCoffee();
}
/**
* 具体工厂类:美式咖啡工厂
*/
public class AmericanCoffeeFactory implements CoffeeFactory {
@Override
public AbstractCoffee createCoffee() {
return new AmericanCoffee();
}
}
/**
* 具体工厂类:拿铁咖啡工厂
*/
public class LatteCoffeeFactory implements CoffeeFactory {
@Override
public AbstractCoffee createCoffee() {
return new LatteCoffee();
}
}
/**
* 咖啡店类,依赖抽象工厂生产咖啡,不关心具体工厂的实现
*/
public class CoffeeStore {
private CoffeeFactory factory;
public CoffeeStore(CoffeeFactory factory){
this.factory = factory;
}
/**
* 调用工厂生产咖啡的方法
* @return AbstractCoffee
*/
public AbstractCoffee orderCoffee() {
return factory.createCoffee();
}
}
可以看到,工厂方法模式,将具体产品的创建细节延迟到了具体工厂当中。如果想要添加新类型的咖啡,只需要编写一个具体咖啡类,让她继承抽象咖啡类,再编写一个具体工厂类,让她实现抽象工厂类,重新实现抽象,生成新咖啡类对象即可,而无需修改原有代码,是符合开闭原则的。对于咖啡店来说,只要告诉她哪个工厂能生产对应的咖啡对象,而不关心怎么生产;她只依赖抽象工厂类,与具体工厂或者具体产品是没有耦合的。真正产生耦合的是具体工厂类与具体产品类之间,这也就决定了工厂方法模式只能是 “专职专用,一个具体工厂只能生产一类对象”。所以,工厂方法模式的缺点也很明显----每增加一个具体产品,就要增加一个具体工厂,增加了系统的复杂度;如果系统后期增加的产品太多,很容易造成 “类爆炸”