2.1工厂方法模式
亦称: 虚拟构造函数、Virtual Constructor、Factory Method
工厂方法模式是一种创建型设计模式, 其在父类中提供一个创建对象的方法, 允许子类决定实例化对象的类型。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-eFIJxewq-1677057283670)(null)]
准备好开始烘烤某些松耦合的OO设计。除了使用new操作符之外,还有更多制造对象的方法。我们将了解到实例化这个活动不应总是公开的进行,也会认识到初始化经常造成“耦合”问题。那么工厂模式将会帮你从复杂的依赖中脱困。
当我们看到new关键字的时候,总是会想到“具体”,不过确实,当我们使用new的时候,的确是在实例化一个对象,所以用的确实是是实现,而不是接口。这是一个好问题,你也已经知道了代买绑着具体的类会导致代码更脆弱,更缺乏弹性。
当有一群相关的具体类时,我们可能想到这样的代码:
Duck duck;
if(picnic){
duck = new MallardDuck();
}else if(hunting){
duck = new DecoyDcuk();
}else{
//.....
}
这些需要实例化的具体类,究竟要实例化哪些类,需要在运行时的一些条件决定。
但是我们需要做的是针对接口编程,可以隔离掉以后系统可能发生的一些改变。
问题
身为披萨店的主人,我们的代码可能这样写:
Pizza orederPizza(){
Pizza pizza = new Pizza();
pizza.prepare();
pizza.bake();
pizza.cut();
pizza.box();
return pizza;
}
但是当我们需要更多的披萨类型怎么办?所以我们需要加入一些代码来决定合适的披萨类型,然后再制造这个披萨。
Pizza pizza ;
if(type1){
return new CheesePizza();
}else if(type2){
return new GreekPizza();
}else{
//......
}
但是压力来自更多增加的披萨类型,每次新增新的类型该怎么办?
解决方案
很明显,如果实例化“某些"具体类,将使orderPizza()出问题,而且也无法让orderPizza()对修改关闭;但是,现在我们已经知道哪些会改变,哪些不会改变,该是时候使用封装了。
封装创建的代码:
我们最好将创建对象移入到orderPizza()对象之外,但是怎么做呢?我们将创建披萨对象的代码单独拿出来,由这个新对象专职创建披萨。
我们需要一个工厂来专门创建披萨
public class SimplePizzaFactory{
public Pizza createPizza(){
Pizza pizza = null ;
if(type1){
pizza = new CheesePizza();
}else if(type2){
pizza =new GreekPizza();
}else{
//......
}
return pizza;
}
}
- 重做PizzaStore类
public class PizzaStore{
SimplePizzaFactory factory;
pubic PizzaStore(SimplePizzaFactory factory){
this.factory = factory;
}
public Pizza createPizza(){
Pizza pizza = null ;
if(type1){
pizza = new CheesePizza();
}else if(type2){
pizza =new GreekPizza();
}else{
//......
}
pizza.prepare();
pizza.bake();
//....
return pizza;
}
}
那么这样一个简单的工厂方法就建立起来了。
由于我们披萨店的生意太火爆了,我们需要加盟新的披萨店,制作新的口味的披萨来吸引顾客,这个时候我们该怎么设计呢?
但是如果只使用一个SimplePizzaFactory
,达不到这样的效果。我们需要一些变量控制。
- 更改PizzaStore类
public abstract class PizzaStore {
public Pizza orderPizza(String type){
Pizza pizza = createPizza(type);
if(pizza == null) return null;
pizza.prepare();
pizza.bake();
pizza.cut();
pizza.box();
return pizza;
}
//不同的门店去重写不同的方法,不用全部委托给自己
protected abstract Pizza createPizza(String type);
}
ChicagoPizzaStore
店
public class ChicagoPizzaStore extends PizzaStore {
@Override
protected Pizza createPizza(String type) {
if("cheese".equals(type)){
return new ChicagoStyleCheesePizza();
}else if("clam".equals(type)){
return new ChicagoStyleClamPizza();
}else {
return null;
}
}
}
NYPizzaStore
店
public class NYPizzaStore extends PizzaStore {
@Override
protected Pizza createPizza(String type) {
if("cheese".equals(type)){
return new NYStyleCheesePizza();
}else if("veggie".equals(type)){
return new NYStyleClamPizza();
}else {
return null;
}
}
}
- 当然也少不了披萨基类
public abstract class Pizza {
public String name;
public String dough;
public String sauce;
/**
* 披萨上面覆盖的小料
*/
public List<String> topping = new ArrayList<>();
public void prepare(){
System.out.println("Preparing:" + name);
System.out.println("Tossing dough...");
System.out.println("Adding sauce...");
System.out.println("Adding toppings..");
for (String top : topping) {
System.out.println(" " + top);
}
}
public void bake(){
System.out.println("bake for 25 minutes at 350");
}
public void cut(){
System.out.println("Cutting the pizza into diagonal slices");
}
public void box(){
System.out.println("Place pizza in official PizzaStore box");
}
public String getName(){
return name;
}
}
ChicagoStyleCheesePizza
披萨
public class ChicagoStyleCheesePizza extends Pizza {
public ChicagoStyleCheesePizza(){
name = "Chicago Style Cheese Pizza";
dough = "Extra Thick Crust Dough";
sauce = "Plum Tomato Sauce";
topping.add("Shredded Mozzarella Cheese");
}
/**
* 覆盖父类的cute方法
*/
public void cut(){
System.out.println("Cutting the pizza into square slices #######");
}
}
NYStyleCheesePizza
披萨
public class NYStyleCheesePizza extends Pizza {
public NYStyleCheesePizza(){
name = "NY Style Sauce and Cheese Pizza";
dough = "Thin Crust Dough";
sauce = "Marinara Sauce";
topping.add("Creatd Reggiano Cheese");
}
}
那么一切准备好之后,怎么开店下订单呢?
- 我们先需要一个披萨店
PizzaStore nyStore = new NYPizzaStore();
- 下对应类型的订单
Pizza pizza = nyStore.orderPizza("cheese");
- 剩下的都是内部封装好的方法
- 具体实现
public class Main {
public static void main(String[] args) {
PizzaStore nyStore = new NYPizzaStore();
PizzaStore chicagoStore = new ChicagoPizzaStore();
Pizza pizza = nyStore.orderPizza("cheese");
System.out.println("Ethan ordered a " + pizza.getName() + "\n");
pizza = chicagoStore.orderPizza("cheese");
System.out.println("Joel ordered a " + pizza.getName() + "\n");
}
}
运行结果:
Preparing:NY Style Sauce and Cheese Pizza
Tossing dough...
Adding sauce...
Adding toppings..
Creatd Reggiano Cheese
bake for 25 minutes at 350
Cutting the pizza into diagonal slices
Place pizza in official PizzaStore box
Ethan ordered a NY Style Sauce and Cheese Pizza
Preparing:Chicago Style Cheese Pizza
Tossing dough...
Adding sauce...
Adding toppings..
Shredded Mozzarella Cheese
bake for 25 minutes at 350
Cutting the pizza into square slices #######
Place pizza in official PizzaStore box
Joel ordered a Chicago Style Cheese Pizza
工厂方法模式结构
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Uk2AxKvw-1677057283696)(null)]
-
产品 (Product) 将会对接口进行声明。 对于所有由创建者及其子类构建的对象, 这些接口都是通用的。
-
具体产品 (Concrete Products) 是产品接口的不同实现。
-
创建者 (Creator) 类声明返回产品对象的工厂方法。 该方法的返回对象类型必须与产品接口相匹配。
你可以将工厂方法声明为抽象方法, 强制要求每个子类以不同方式实现该方法。 或者, 你也可以在基础工厂方法中返回默认产品类型。
注意, 尽管它的名字是创建者, 但它最主要的职责并不是创建产品。 一般来说, 创建者类包含一些与产品相关的核心业务逻辑。 工厂方法将这些逻辑处理从具体产品类中分离出来。 打个比方, 大型软件开发公司拥有程序员培训部门。 但是, 这些公司的主要工作还是编写代码, 而非生产程序员。
-
具体创建者 (Concrete Creators) 将会重写基础工厂方法, 使其返回不同类型的产品。
注意, 并不一定每次调用工厂方法都会创建新的实例。 工厂方法也可以返回缓存、 对象池或其他来源的已有对象。
工厂方法模式适合应用场景
当你在编写代码的过程中, 如果无法预知对象确切类别及其依赖关系时, 可使用工厂方法。
工厂方法将创建产品的代码与实际使用产品的代码分离, 从而能在不影响其他代码的情况下扩展产品创建部分代码。
例如, 如果需要向应用中添加一种新产品, 你只需要开发新的创建者子类, 然后重写其工厂方法即可。
如果你希望用户能扩展你软件库或框架的内部组件, 可使用工厂方法。
继承可能是扩展软件库或框架默认行为的最简单方法。 但是当你使用子类替代标准组件时, 框架如何辨识出该子类?
解决方案是将各框架中构造组件的代码集中到单个工厂方法中, 并在继承该组件之外允许任何人对该方法进行重写。
让我们看看具体是如何实现的。 假设你使用开源 UI 框架编写自己的应用。 你希望在应用中使用圆形按钮, 但是原框架仅支持矩形按钮。 你可以使用 圆形按钮
RoundButton子类来继承标准的 按钮
Button类。 但是, 你需要告诉 UI框架
UIFramework类使用新的子类按钮代替默认按钮。
为了实现这个功能, 你可以根据基础框架类开发子类 圆形按钮 UI
UIWithRoundButtons , 并且重写其 createButton
创建按钮方法。 基类中的该方法返回 按钮
对象, 而你开发的子类返回 圆形按钮
对象。 现在, 你就可以使用 圆形按钮 UI
类代替 UI框架
类。 就是这么简单!
如果你希望复用现有对象来节省系统资源, 而不是每次都重新创建对象, 可使用工厂方法。
在处理大型资源密集型对象 (比如数据库连接、 文件系统和网络资源) 时, 你会经常碰到这种资源需求。
让我们思考复用现有对象的方法:
- 首先, 你需要创建存储空间来存放所有已经创建的对象。
- 当他人请求一个对象时, 程序将在对象池中搜索可用对象。
- … 然后将其返回给客户端代码。
- 如果没有可用对象, 程序则创建一个新对象 (并将其添加到对象池中)。
这些代码可不少! 而且它们必须位于同一处, 这样才能确保重复代码不会污染程序。
可能最显而易见, 也是最方便的方式, 就是将这些代码放置在我们试图重用的对象类的构造函数中。 但是从定义上来讲, 构造函数始终返回的是新对象, 其无法返回现有实例。
因此, 你需要有一个既能够创建新对象, 又可以重用现有对象的普通方法。 这听上去和工厂方法非常相像。
实现方式
-
让所有产品都遵循同一接口。 该接口必须声明对所有产品都有意义的方法。
-
在创建类中添加一个空的工厂方法。 该方法的返回类型必须遵循通用的产品接口。
-
在创建者代码中找到对于产品构造函数的所有引用。 将它们依次替换为对于工厂方法的调用, 同时将创建产品的代码移入工厂方法。
你可能需要在工厂方法中添加临时参数来控制返回的产品类型。
工厂方法的代码看上去可能非常糟糕。 其中可能会有复杂的
switch
分支运算符, 用于选择各种需要实例化的产品类。 但是不要担心, 我们很快就会修复这个问题。 -
现在, 为工厂方法中的每种产品编写一个创建者子类, 然后在子类中重写工厂方法, 并将基本方法中的相关创建代码移动到工厂方法中。
-
如果应用中的产品类型太多, 那么为每个产品创建子类并无太大必要, 这时你也可以在子类中复用基类中的控制参数。
例如, 设想你有以下一些层次结构的类。 基类
邮件
及其子类航空邮件
和陆路邮件
;运输
及其子类飞机
,卡车
和火车
。航空邮件
仅使用飞机
对象, 而陆路邮件
则会同时使用卡车
和火车
对象。 你可以编写一个新的子类 (例如火车邮件
) 来处理这两种情况, 但是还有其他可选的方案。 客户端代码可以给陆路邮件
类传递一个参数, 用于控制其希望获得的产品。 -
如果代码经过上述移动后, 基础工厂方法中已经没有任何代码, 你可以将其转变为抽象类。 如果基础工厂方法中还有其他语句, 你可以将其设置为该方法的默认行为。
工厂方法模式优缺点
优点:
- 你可以避免创建者和具体产品之间的紧密耦合。
- 单一职责原则。 你可以将产品创建代码放在程序的单一位置, 从而使得代码更容易维护。
- 开闭原则。 无需更改现有客户端代码, 你就可以在程序中引入新的产品类型。
缺点:
- 应用工厂方法模式需要引入许多新的子类, 代码可能会因此变得更复杂。 最好的情况是将该模式引入创建者类的现有层次结构中。
与其他模式的关系
- 在许多设计工作的初期都会使用工厂方法模式 (较为简单, 而且可以更方便地通过子类进行定制), 随后演化为使用抽象工厂模式、 原型模式或生成器模式 (更灵活但更加复杂)。
- 抽象工厂模式通常基于一组工厂方法, 但你也可以使用原型模式来生成这些类的方法。
- 你可以同时使用工厂方法和迭代器模式来让子类集合返回不同类型的迭代器, 并使得迭代器与集合相匹配。
- 原型并不基于继承, 因此没有继承的缺点。 另一方面, 原型需要对被复制对象进行复杂的初始化。 工厂方法基于继承, 但是它不需要初始化步骤。
- 工厂方法是模板方法模式的一种特殊形式。 同时, 工厂方法可以作为一个大型模板方法中的一个步骤。
参考:First Head设计模式、[设计模式](