《详解23种设计模式--工厂模式 | CSDN创作打卡》

• 《详解23种设计模式–单例模式 | CSDN创作打卡》

坚持就是胜利，打卡第二篇

本次学习基于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();
    }

}

可以看到，工厂方法模式，将具体产品的创建细节延迟到了具体工厂当中。如果想要添加新类型的咖啡，只需要编写一个具体咖啡类，让她继承抽象咖啡类，再编写一个具体工厂类，让她实现抽象工厂类，重新实现抽象，生成新咖啡类对象即可，而无需修改原有代码，是符合开闭原则的。对于咖啡店来说，只要告诉她哪个工厂能生产对应的咖啡对象，而不关心怎么生产；她只依赖抽象工厂类，与具体工厂或者具体产品是没有耦合的。真正产生耦合的是具体工厂类与具体产品类之间，这也就决定了工厂方法模式只能是 “专职专用，一个具体工厂只能生产一类对象”。所以，工厂方法模式的缺点也很明显----每增加一个具体产品，就要增加一个具体工厂，增加了系统的复杂度；如果系统后期增加的产品太多，很容易造成 “类爆炸”