4.1 Factory Method 模式
在 Template Method 模式中,我们在父类中规定处理的流程,在子类中实现具体的处理。如果我们将该模式用于生成实例,它就演变为这里我们将学习的 Factroy Method 模式。
Factory 有 “工厂” 的意思。用 Template Method 模式来构建生成实例的工厂,这就是 Factory Method 模式。在该模式中,父类决定实例的生成方式,但并不决定要生产的具体的类,具体的处理全部交给子类负责。这样就可以将生产实例的框架和实际负责生成实例的类解耦。
4.2 示例程序
下面的一段 Factory Method 模式的示例程序,作用是制作身份证,它其中有 5 个类。
Product 类和 Factory 类属于 framework 包,这两个类组成了生成实例的框架。
IDCard 类和 IDCardFactory 类负责实际的加工处理,属于 idcard 包。
Main 类与之前一样,用于测试程序行为。
|| Product 类
framework 包中的 Product 类用来表示 “产品” 的类。该类中仅声明了 use 抽象方法,具体的实现交由子类负责。这里定义了产品是 “任意可以 use ” 的东西。
package cn.onlyll.framework;
/**
*
* describe 简单工厂生产对象抽象类
* @author xmc
* @date 2019/3/24 15:31
*/
public abstract class Product {
public abstract void use();
}
|| Factory 类
framework 包中的 Factory 类,我们使用了 Template Method 模式。该类还声明了用于 “生成产品” 的 createProduct 抽象方法和用于 “注册产品” 的 registerProduct 抽象方法。具体处理交由子类负责。
这个框架中,我们定义了工厂是用来 “调用 create 方法生成 Product 实例” 的。而 create 方法的实现是先调用 createProduct 生成产品,接着调用 registerProduct 注册产品。
具体的实现内容根据 Factory Method 模式适用的场景不同而不同。但是,只要是 Factory Method 模式,在生成实例时就一定会使用到 Template Method 模式。
package cn.onlyll.framework;
/**
*
* describe 工厂抽象类
* @author xmc
* @date 2019/3/24 15:43
*/
public abstract class Factory {
public final Product create(String owner) {
// 先构建产品,然后注册
Product p = createProduct(owner);
registerProduct(p);
return p;
}
// 创建产品
public abstract Product createProduct(String owner);
// 注册产品
public abstract void registerProduct(Product product);
}
|| IDCard 类
为了能够明显地体现出与框架的分离,我们将这个类放在 idcard 包中。
IDCard 是产品 Product 类的子类。
package cn.onlyll.idcard;
import cn.onlyll.framework.Product;
/**
*
* describe 实际产品
* @author xmc
* @date 2019/3/24 15:51
*/
public class IDCard extends Product {
private String owner;
IDCard(String owner) {
System.out.println("制作 " + owner + " 的 ID 卡。");
this.owner = owner;
}
@Override
public void use() {
System.out.println("使用 " + owner + " 的 ID 卡。");
}
public String getOwner() {
return owner;
}
}
|| IDCardFactory 类
IDCardFactory 类实现了 createProduct 、registerProduct 方法。前者通过生成 IDCard 的实例来“生成产品”,后者通过将 IDCard 的 owner 保存到 owners 字段中来实现 “注册产品”。
package cn.onlyll.idcard;
import cn.onlyll.framework.Factory;
import cn.onlyll.framework.Product;
import java.util.ArrayList;
import java.util.List;
/**
*
* describe 工厂实现类
* @author xmc
* @date 2019/3/24 15:55
*/
public class IDCardFactory extends Factory {
private List<String> owners = new ArrayList<>();
@Override
public Product createProduct(String owner) {
return new IDCard(owner);
}
@Override
public void registerProduct(Product product) {
// 强转为 IDCard 类,进行注册
owners.add(((IDCard)product).getOwner());
}
}
|| Main 类
使用 framework 和 idcard 包来制作和使用 IDCard。
package cn.onlyll;
import cn.onlyll.framework.Factory;
import cn.onlyll.framework.Product;
import cn.onlyll.idcard.IDCardFactory;
public class Main {
public static void main(String[] args) {
Factory idFactory = new IDCardFactory();
Product card1 = idFactory.create("小明");
Product card2 = idFactory.create("小黑");
Product card3 = idFactory.create("小白");
card1.use();
card2.use();
card3.use();
}
}
运行输出结果:
制作 小明 的 ID 卡。
制作 小黑 的 ID 卡。
制作 小白 的 ID 卡。
使用 小明 的 ID 卡。
使用 小黑 的 ID 卡。
使用 小白 的 ID 卡。
4.3 Factory Method 中登场的角色
在 Factory Method 中有以下登场角色。查看其类图,我们可以知道,父类(框架)这一方的 Creator 角色和 Product 角色的关系与子类(具体加工)这一方的 ConcreteCreator 角色和 ConcreteProduct 角色的关系是平行的。
- Product (产品)
Product 角色属于框架这一方,是一个抽象类。它定义了在 Factory Method 模式中生成的那些实例所持有的接口,但具体的处理则由子类 ConcreteProduct 角色决定。 - Creator (创建者)
Creator 角色属于框架这一方,负责生成 Product 角色的抽象类,但具体的处理则由子类 ConcreteCreator 角色决定。
Creator 角色对实际负责生成实例的 ConcreteCreator 角色一无所知,唯一知道的就是,只要调用 Product 角色和生成实例的方法(factoryMethod),就可以生成 Product 的实例。
不用 new 关键字来生成实例,而是调用生成实例的专用方法来生成实例,这样就可以防止父类与其他具体类耦合。 - ConcreteProduct(具体的产品)
ConcreteCreator 角色属于具体加工这一方,它决定了具体的产品。 - ConcreteCreator (具体的创建者)
ConcreteCreator 角色属于具体加工这一方,它负责生成具体的产品。
4.4 扩展思路的要点
|| 框架与具体加工
这里,我们分别学习了 “框架” 与 “具体加工” 这两方面的内容。它们分别封装在 framework 和 idcard 包中。
在 framework 包中我们并没有引入 idcard 包。在 Product 类和 Factory 类中,并没有出现 IDCard 和 IDCardFactory 等具体类的名字。因此,使用已有的框架生成全新的类时,也完全不需要对 framework 进行修改。我们称作 “framework 包不依赖于 idcard 包”。
|| 生成实例-方法的三种实现方式
creteProduct 方法的实现方式一般有一下3种。
- 指定其为抽象方法
一旦将 creteProduct 指定为抽象方法后,子类就必须实现该方法。不实现,编译器将会报告错误。这也是示例程序采用的方式。 - 为其实现默认处理
实现默认处理后,如果子类没有实现该方法,将进行默认处理。
不过,此时是使用 new 关键字创建出实例,所以不能将 Product 类定义为抽象类。
class Factory {
public Product createProduct(String name) {
return new Product(name);
}
}
- 在其中抛出异常
createProduct 方法默认处理为抛出异常,这样,如果未在子类中试下该方法,程序就会在运行时出错(比如,提示开发人员没有实现 createProduct方法)。
class Factory {
public Product createProduct(String name) {
throw new FactoryMethodRuntimeException();
}
...
}
|| 使用模式与开发人员之间的沟通
不论是模版方法或本章的工厂方法,在实际工作中使用时,都会让我们感觉到比较困难。因为,如果仅阅读一个类的代码,是很难理解这个类的行为的。必须要理解父类中所定义的处理的框架和它里面所使用的抽象方法,然后阅读代码,了解这些抽象方法在子类中的实现才行。
通常,使用设计模式设计类时,需要向维护这些类的开发人员正确地传达设计这些设计模式的意图。否则,维护人员在修改设计时可能会违背设计者最初的意图。
建议在程序注释中和开发文档中记录所使用的设计模式的名称和意图。