工厂模式的核心目的是封装对象创建过程，解耦创建与使用，提升灵活性和可维护性，主要有三种实现方式：1. 简单工厂由一个工厂类根据参数创建所有产品，适用于产品种类少且稳定的场景，但违背开闭原则；2. 工厂方法通过抽象工厂接口让子类决定创建哪个产品，符合开闭原则，适合产品类型多且需扩展的场景，但类数量增加；3. 抽象工厂用于创建一组相关或依赖的产品族，适合跨平台或主题切换等场景，但结构复杂且扩展新产品类型困难。
工厂模式在Java设计模式中，核心目的都是为了封装对象的创建过程，从而将对象的创建与使用分离，降低代码的耦合度，提升系统的灵活性和可维护性。它主要有三种常见的实现方式：简单工厂（Simple Factory）、工厂方法（Factory Method）和抽象工厂（Abstract Factory），它们各有侧重，适用于不同的场景。
解决方案
工厂模式，顾名思义，就是像一个工厂一样，负责“生产”对象。这三种模式在实现上各有千秋，但都围绕着“解耦创建逻辑”这个核心思想。
1. 简单工厂模式（Simple Factory Pattern）
立即学习“Java免费学习笔记（深入）”；
这可能是我们日常编码中最容易想到的，也是最“不那么”像设计模式的设计模式。它通常包含一个工厂类，这个类里有一个静态方法，根据传入的参数来决定创建并返回哪种具体的产品对象。
核心思想： 由一个工厂类负责所有产品的创建。优点：简单易用： 代码量少，理解成本低，对于少量产品类型非常方便。集中管理： 所有的创建逻辑都集中在一个地方，方便修改。缺点：违背开闭原则（Open/Closed Principle）： 每增加一种新产品，都需要修改工厂类的创建逻辑（通常是if-else或switch-case语句），这会导致工厂类变得臃肿且难以维护。职责过重： 工厂类承担了所有产品的创建职责。适用场景： 产品种类较少且相对稳定，或者只是为了简单地封装创建过程，不想引入过多复杂度的场景。
// 产品接口interface Product { void use();}// 具体产品Aclass ConcreteProductA implements Product { @Override public void use() { System.out.println("使用产品A"); }}// 具体产品Bclass ConcreteProductB implements Product { @Override public void use() { System.out.println("使用产品B"); }}// 简单工厂class SimpleProductFactory { public static Product createProduct(String type) { if ("A".equalsIgnoreCase(type)) { return new ConcreteProductA(); } else if ("B".equalsIgnoreCase(type)) { return new ConcreteProductB(); } else { throw new IllegalArgumentException("未知产品类型: " + type); } }}// 客户端使用public class Client { public static void main(String[] args) { Product productA = SimpleProductFactory.createProduct("A"); productA.use(); // 输出: 使用产品A Product productB = SimpleProductFactory.createProduct("B"); productB.use(); // 输出: 使用产品B }}
2. 工厂方法模式（Factory Method Pattern）
这是为了解决简单工厂模式中违反开闭原则的问题而诞生的。它将产品对象的创建延迟到子类工厂中。每个具体产品都对应一个具体的工厂类。
核心思想： 定义一个用于创建对象的接口，让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到其子类。优点：符合开闭原则： 增加新产品时，只需增加新的具体产品类和对应的具体工厂类，无需修改现有代码。职责单一： 每个工厂只负责创建一种产品。客户端与具体产品解耦： 客户端只与抽象工厂和抽象产品交互。缺点：类数量增加： 每增加一个产品，就需要增加一个对应的工厂类，导致类的数量膨胀，增加了系统的复杂性。适用场景： 当一个类不知道它所需要的对象的类时；当一个类希望它的子类来指定它所创建的对象时。这是最常用的一种工厂模式。
// 产品接口 (同上)// interface Product { void use(); }// class ConcreteProductA implements Product { ... }// class ConcreteProductB implements Product { ... }// 抽象工厂接口interface ProductFactory { Product createProduct();}// 具体产品A的工厂class ConcreteProductAFactory implements ProductFactory { @Override public Product createProduct() { return new ConcreteProductA(); }}// 具体产品B的工厂class ConcreteProductBFactory implements ProductFactory { @Override public Product createProduct() { return new ConcreteProductB(); }}// 客户端使用public class Client { public static void main(String[] args) { ProductFactory factoryA = new ConcreteProductAFactory(); Product productA = factoryA.createProduct(); productA.use(); // 输出: 使用产品A ProductFactory factoryB = new ConcreteProductBFactory(); Product productB = factoryB.createProduct(); productB.use(); // 输出: 使用产品B }}
3. 抽象工厂模式（Abstract Factory Pattern）
这是工厂模式中最复杂的一种，它不仅创建单个产品，而是创建一系列相关或相互依赖的产品对象，而无需指定它们具体的类。
核心思想： 提供一个接口，用于创建相关或依赖对象的家族，而无需明确指定具体类。优点：提供一个产品族的抽象接口： 确保客户端使用一个产品族中的多个对象是相互兼容的。客户端与具体工厂和产品解耦： 客户端完全不知道具体的产品和工厂实现。易于切换产品族： 改变一个产品族的实现，只需切换具体的工厂即可。缺点：增加复杂性： 引入了更多的接口和类，理解和维护成本更高。难以扩展新产品类型： 如果要增加新的产品类型（而不是新的产品族），需要修改所有的抽象工厂和具体工厂，违反开闭原则。适用场景： 当需要创建一组相关或相互依赖的对象时；当系统需要独立于这些对象的创建、组合和表示时。比如，一个UI库需要支持多种操作系统主题（Windows风格、Mac风格），每种主题下有按钮、文本框等控件，这些控件在同一主题下是相互兼容的。
// 抽象产品A接口interface AbstractProductA { void showA();}// 抽象产品B接口interface AbstractProductB { void showB();}// 具体产品A1class ConcreteProductA1 implements AbstractProductA { @Override public void showA() { System.out.println("这是产品A1"); }}// 具体产品A2class ConcreteProductA2 implements AbstractProductA { @Override public void showA() { System.out.println("这是产品A2"); }}// 具体产品B1class ConcreteProductB1 implements AbstractProductB { @Override public void showB() { System.out.println("这是产品B1"); }}// 具体产品B2class ConcreteProductB2 implements AbstractProductB { @Override public void showB() { System.out.println("这是产品B2"); }}// 抽象工厂接口interface AbstractFactory { AbstractProductA createProductA(); AbstractProductB createProductB();}// 具体工厂1，生产产品A1和B1class ConcreteFactory1 implements AbstractFactory { @Override public AbstractProductA createProductA() { return new ConcreteProductA1(); } @Override public AbstractProductB createProductB() { return new ConcreteProductB1(); }}// 具体工厂2，生产产品A2和B2class ConcreteFactory2 implements AbstractFactory { @Override public AbstractProductA createProductA() { return new ConcreteProductA2(); } @Override public AbstractProductB createProductB() { return new ConcreteProductB2(); }}// 客户端使用public class Client { public static void main(String[] args) { AbstractFactory factory1 = new ConcreteFactory1(); AbstractProductA productA1 = factory1.createProductA(); AbstractProductB productB1 = factory1.createProductB(); productA1.showA(); // 输出: 这是产品A1 productB1.showB(); // 输出: 这是产品B1 AbstractFactory factory2 = new ConcreteFactory2(); AbstractProductA productA2 = factory2.createProductA(); AbstractProductB productB2 = factory2.createProductB(); productA2.showA(); // 输出: 这是产品A2 productB2.showB(); // 输出: 这是产品B2 }}
为什么我们需要工厂模式？
说实话，刚接触设计模式的时候，我个人觉得工厂模式有点“小题大做”。不就是new一个对象吗？直接new不香吗？但随着项目规模的扩大，我逐渐意识到，直接new带来的问题远比想象中要多。这背后其实是对“依赖”的深刻理解。
我们直接new一个对象时，比如Product p = new ConcreteProductA();，我们的代码就直接依赖于ConcreteProductA这个具体的类。如果哪天ConcreteProductA的构造函数变了，或者我们需要换成ConcreteProductB，那么所有直接new的地方都得改。这在大型项目中简直是灾难。
比格设计
比格设计是135编辑器旗下一款一站式、多场景、智能化的在线图片编辑器
124 查看详情 
工厂模式的核心价值，就在于它把“谁来创建对象”这个职责给抽象并封装起来了。客户端代码不再直接关心具体产品是如何被创建的，它只关心抽象的产品接口。这样一来，我们的业务逻辑代码就能专注于处理业务本身，而不用被底层的对象创建细节所干扰。这大大提升了代码的解耦性和可维护性。想象一下，如果你的系统需要支持多种数据库，直接new MySQLConnection、new OracleConnection，那改起来简直要命。但如果通过工厂来获取连接，切换就变得轻而易举。
三种工厂模式的适用场景与权衡
我们已经看到了这三种模式的实现方式，但更重要的是，什么时候该用哪个？这其实是一个权衡的过程，没有绝对的“最好”，只有最适合当前上下文的。
简单工厂，我通常把它看作是“初级封装”。它最简单，上手快，如果你只是想把一些散乱的new操作集中起来，或者你的产品类型非常少，而且未来基本不会变动，那么简单工厂是你的不二之选。比如，一个工具类，根据传入的字符串返回不同的解析器实例。它的缺点在于，一旦产品种类增多，那个工厂方法里的if-else链条就会变得很长，每次新增产品都要修改它，这就违反了开闭原则，维护起来会很头疼。
工厂方法，在我看来，是工厂模式的“主力军”。它解决了简单工厂的扩展性问题。当你预计系统会不断增加新的产品类型时，工厂方法就显得尤为重要。它通过引入抽象工厂和具体工厂，将创建的职责下放到子类，完美地符合了开闭原则。每次新增产品，你只需要添加一个新的具体产品类和一个新的具体工厂类，对现有代码几乎没有影响。它的代价是类文件数量会显著增加。对于一个产品，你可能需要一个产品接口、一个具体产品类、一个工厂接口、一个具体工厂类，这一下子就多了四份代码。但为了系统的可扩展性，这种“臃肿”是值得的。
抽象工厂，这是工厂模式中的“重型武器”，也是最复杂的。它不是为了创建单个产品，而是为了创建“产品族”。想象一下，你正在开发一个跨平台的GUI应用，需要同时支持Windows和macOS风格的界面。Windows风格的按钮和文本框，与macOS风格的按钮和文本框，它们各自形成一个“家族”。抽象工厂就能让你在不修改客户端代码的情况下，轻松切换整个产品家族。它的缺点是显而易见的：复杂性急剧上升。而且，如果你想新增一个产品“类型”（比如，除了按钮和文本框，现在还要增加一个滑块），那么所有的抽象工厂和具体工厂都需要修改，这又是一个违反开闭原则的地方。所以，除非你真的有“产品族”的需求，否则不要轻易使用抽象工厂，过度设计带来的麻烦可能比它解决的问题还要多。
实践中的选择：何时从简单转向复杂？
在我的实际开发经验中，一个很关键的点是不要过度设计。我个人倾向于在起步阶段保持简单，但心里要清楚，一旦业务逻辑开始膨胀，就得考虑升级了。
通常，我会从简单工厂开始。如果项目初期产品类型不多，或者需求变动不大，简单工厂足够满足需求。它能快速搭建起创建逻辑的雏形，避免了最初就引入过多不必要的复杂性。
然而，当你的产品列表开始变得冗长，或者你发现自己频繁地修改简单工厂中的if-else语句来添加新产品时，这就是一个明确的信号：你该升级到工厂方法了。这种升级通常是渐进的，你可以先将最常变动的产品类型抽取出来，用工厂方法来管理。一旦你开始感受到简单工厂带来的维护负担，工厂方法模式的引入就显得水到渠成，它会让你在产品扩展时感到非常顺畅。
至于抽象工厂，它是一个更高级别的抽象，只有当你面临创建“产品族”的需求时，才应该考虑它。比如，你的系统需要同时支持多种主题、多种皮肤、或者不同系列的产品（如Intel系列CPU和AMD系列CPU，它们各自有一套主板、内存等配套产品）。如果你的需求仅仅是创建单一类型的产品，即使有很多种，工厂方法也足够了。不要为了用设计模式而用设计模式，因为抽象工厂的复杂性是实实在在的，它会增加学习曲线和维护成本。
总结一下，我的选择路径是：简单工厂 -> 工厂方法 -> 抽象工厂。从最简单的开始，随着业务复杂度的提升和对可扩展性要求的增加，逐步引入更复杂的模式。这就像盖房子，一开始可能只需要一个简单的棚子，但随着家庭成员的增加和生活需求的提升，你才需要考虑建造多层别墅，而不是一开始就规划一个宫殿。设计模式是解决问题的工具，不是炫技的手段。
以上就是Java设计模式之工厂模式的三种实现方式对比的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/252716.html
微信扫一扫 
支付宝扫一扫 
![[1039]linux使用sz命令下载大于4G的文件到windows](https://www.chuangxiangniao.com/wp-content/uploads/2025/11/175824325972881.jpg)
![[1039]linux使用sz命令下载大于4G的文件到windows](https://www.chuangxiangniao.com/wp-content/uploads/2025/11/175824325970115.jpg)
![[1039]linux使用sz命令下载大于4G的文件到windows](https://www.chuangxiangniao.com/wp-content/uploads/2025/11/175824325958849.jpg)
![[1039]linux使用sz命令下载大于4G的文件到windows](https://www.chuangxiangniao.com/wp-content/uploads/2025/11/68b6d67b6aa55254-8.png)
