【设计模式】工厂方法模式Factory：解决生成对象时的不确定性-CFANZ编程社区

(目录)

工厂方法模式：解决生成对象时的不确定性

和抽象工厂模式很类似，但工厂方法模式因为只围绕着一类接口来进行对象的创建与使用，使用场景更简单和单一，在实际的项目中使用频率反而比抽象工厂模式更高。

原理

工厂方法模式的原始定义是：

定义一个创建对象的接口，但让实现这个接口的类来决定实例化哪个类。

这种创建⽅式不会对外暴露创建细节，并且会通过⼀个统⼀的接⼝创建所需对象。

工厂方法模式的目的很简单，就是封装对象创建的过程，提升创建对象方法的可复用性。

工厂方法模式的 UML 图：

工厂方法模式包含三个关键角色：

1.抽象接口（也叫抽象产品）； 2.核心工厂； 3.具体产品（也可以是具体工厂）。

其中，核心工厂通常作为父类负责定义创建对象的抽象接口以及使用哪些具体产品，具体产品可以是一个具体的类，也可以是一个具体工厂类，负责生成具体的对象实例。于是，工厂方法模式便将对象的实例化操作延迟到了具体产品子类中去完成。

不同于抽象工厂模式，工厂方法模式侧重于直接对具体产品的实现进行封装和调用，通过统一的接口定义来约束程序的对外行为。换句话说，用户通过使用核心工厂来获得具体实例对象，再通过对象的统一接口来使用对象功能。

案例分析：小白买电脑

下⾯我⽤可以利⽤

以电脑店为例，我是⼀个纯⼩⽩，⾯对琳琅满⽬的各种电脑⼀脸懵X，根本⽆从下⼿~

电脑Computer 接⼝

public interface Computer {
 public String describe();
}

实现类(具体产品)：

外星⼈游戏笔记本

public class Alienware implements Computer{
    @Override
    public String describe() {
        return "外星人ALIENWARE m15 R7 15.6英寸高端游戏本 12代i7 32G RTX3060 QHD 240Hz 高刷屏 轻薄笔记本电脑2765QB";
    }
}

⾼性能独显PC主机

public class Desktop implements Computer{
    @Override
    public String describe() {
        return "外星人ALIENWARE R13 水冷电竞游戏高端台式机 第12代i7 32G 512GB+2T RTX3070 办公台式机 9776W";
    }
}

Macbook办公轻薄本

public class Macbook implements Computer{
    @Override
    public String describe() {
        return "Apple MacBook Pro 13.3 八核M1芯片 8G 256G SSD 深空灰 笔记本电脑 轻薄本 MYD82CH/A";
    }
}

2U戴尔服务器

public class Server implements Computer{
    @Override
    public String describe() {
        return "戴尔（DELL） R740丨R750丨2U机架式服务器主机双路GPU深度学习 R740〖1*银牌4210R 10核20线程〗 8G内存丨1TB SATA硬盘 丨H350戴尔（DELL） R740丨R750丨2U机架式服务器主机双路GPU深度学习 R740〖1*银牌4210R 10核20线程〗 8G内存丨1TB SATA硬盘 丨H350戴尔（DELL） R740丨R750丨2U机架式服务器主机双路GPU深度学习 R740〖1*银牌4210R 10核20线程〗 8G内存丨1TB SATA硬盘 丨H350戴尔（DELL） R740丨R750丨2U机架式服务器主机双路GPU深度学习 R740〖1*银牌4210R 10核20线程〗 8G内存丨1TB SATA硬盘 丨H350戴尔（DELL） R740丨R750丨2U机架式服务器主机双路GPU深度学习 R740〖1*银牌4210R 10核20线程〗 8G内存丨1TB SATA硬盘 丨H350戴尔（DELL） R740丨R750丨2U机架式服务器主机双路GPU深度学习 R740〖1*银牌4210R 10核20线程〗 8G内存丨1TB SATA硬盘 丨H350戴尔（DELL） R740丨R750丨2U机架式服务器主机双路GPU深度学习 R740〖1*银牌4210R 10核20线程〗 8G内存丨1TB SATA硬盘 丨H350";
    }
}

此时顾客将⾯对⼏⼗种不同性能，不同规格不同种类的电脑，难道顾客必须了解所有细节才能决定使⽤哪⼀个吗？

这⾥就破坏了“迪⽶特法则（知道的越少越好）”，⼤多数客户并不需要了解每⼀台细节，我们要把选择权交还给电脑店这⼀⽅。

错误做法

控制权在顾客⽅是不对的

我们需要⼀个⼯⼚类，帮助顾客进⾏决策，这样控制权掌握

正确做法

增加⼀个售货员帮助⽤户实现决策，根据客户的不同要求提供对应的产品。

这个售货员就是充当了“⼯⼚"的⻆⾊。

⼯⼚模式的特点：提供⽅法，返回接⼝。

public class ShopAssistant {
    public Computer suggest(String purpose){
        Computer computer = null;
        if(purpose.equals("网站建设")){
            return new Server();
        }else if(purpose.equals("电竞比赛")){
            return new Desktop();
        }else if(purpose.equals("日常办公")){
            return new Macbook();
        }else if(purpose.equals("3A游戏")){
            return new Alienware();
        }
        return computer;
    }
}

站在顾客这⼀⽅，获取对象的过程变得⾮常简单，通过售货员这个⼯⼚帮助我们获取需要的对象，同时

不再关注对象创建的过程与细节。

public class Customer {
    public static void main(String[] args) {
        ShopAssistant shopAssistant = new ShopAssistant();
        Computer c = shopAssistant.suggest("3A游戏");
        System.out.println(c.describe());
    }
}