依赖注入 vs 工厂模式：深入解析与实战指南

在软件开发的日常工作中，你是否也曾面临过这样的困境：随着项目功能的日益增加，代码变得越来越难以维护？当你尝试修改一个小功能时，是否引发了“蝴蝶效应”，导致系统中看似无关的其他模块崩溃？如果你有过类似的经历，那么恭喜你，你触碰到了软件开发中最核心的挑战之一——耦合度。

为了解决这一问题，我们拥有两种非常强大的武器：依赖注入 和 工厂模式。很多开发者在使用时常常混淆它们，或者不确定在何种场景下应该选择哪一个。别担心，在这篇文章中，我们将像拆解老式钟表一样，深入探讨这两种设计模式的内部机制，通过实际的代码示例和场景分析，帮助你彻底掌握它们。我们将不仅学习“它们是什么”，更重要的是“如何在正确的时机使用正确的工具”，并结合 2026年的前沿开发趋势，看看这两种经典模式如何在云原生和AI原生时代焕发新生。

核心概念解析：不仅仅是创建对象

什么是依赖注入 (DI) 模式？

让我们从最基础的概念开始。依赖注入不仅仅是一种设计模式，更是一种工程哲学。它的核心思想非常简单：不要在我们需要使用的地方直接创建依赖项，而是让外部将这些依赖项“送”给我们。

想象一下，你需要一把螺丝刀。如果每次用到螺丝刀你都要自己造一把（使用 new 关键字），那你的工作台就会乱成一团，而且如果你想把螺丝刀换成扳手，你就得修改你自己动手造工具的代码。依赖注入就是有一个专门的“工具管理员”（或者是框架），当你需要工具时，他直接递给你一把现成的。你不需要知道这把工具是哪里来的，也不需要知道它是怎么造出来的，你只需要知道怎么用它。

在软件工程中，这意味着一个类不需要在其内部实例化它所依赖的组件。相反，这些依赖项是通过构造函数、Setter 方法或接口从外部传递进来的。

为什么我们要这样做？

• 灵活性： 我们可以在运行时轻松地更换依赖项的实现。例如，从开发环境切换到生产环境，只需要注入不同的数据库服务即可，而无需修改业务逻辑代码。
• 可测试性： 这是 DI 最受开发者喜爱的原因之一。在编写单元测试时，我们可以轻松地注入“模拟对象”来代替真实的、复杂的依赖（比如真实的数据库连接），从而确保测试的隔离性和速度。
• 可维护性： 代码不再纠缠于对象的创建细节，逻辑变得更加清晰，维护起来自然得心应手。

什么是工厂模式？

与依赖注入关注“如何获取依赖”不同，工厂模式 关注的是“如何创建对象”。它是一种创建型设计模式，旨在解决对象创建过程中的复杂性。

试想一下，你要创建一辆复杂的汽车。如果你直接在主程序中写代码组装引擎、轮胎、座椅，代码会变得非常冗长且容易出错。工厂模式就像是汽车制造厂。你只需要按下按钮（调用工厂方法），工厂就会按照预定的流程，处理好所有的细节，并交付给你一辆完整的汽车。

具体来说，工厂方法模式定义了一个创建对象的接口，但由子类决定要实例化的类是哪一个。工厂方法让类把实例化推迟到子类。

它的核心价值在于：

• 封装创建逻辑： 将复杂的初始化逻辑（例如读取配置文件、建立网络连接）隐藏在工厂类内部，调用者无需关心这些细节。
• 解耦： 调用者通过抽象接口（工厂）与具体的类解耦，符合依赖倒置原则。

2026 视角下的技术演进：从“代码模式”到“架构基础设施”

在深入代码实战之前，我们需要先更新一下我们的认知。到了2026年，随着 Serverless、eBPF 和 WebAssembly (Wasm) 的普及，依赖注入和工厂模式的角色发生了一些微妙的变化。

1. 混合单体与模块化单体

微服务虽然流行，但在2026年，我们看到了大量“回吐”到模块化单体的趋势。在这种架构下，DI 容器不仅仅是用来注入依赖的，它变成了模块间的通信总线。我们不再通过 HTTP 调用另一个微服务，而是通过 DI 动态注入一个本地接口实现，这个实现可能在同一个进程内，也可能通过 Sidecar 模式在 Wasm 虚拟机中运行。

2. 工厂模式的“服务发现”化

传统的工厂类里的 switch-case 逻辑在 2026 年看来显得有些过时。现代应用更倾向于使用 Service Mesh (服务网格) 或 动态配置中心 来实现工厂模式。换句话说，工厂不再硬编码创建逻辑，而是查询配置中心：“在这个 Kubernetes Pod 中，我该使用哪个版本的加密算法实现？”这实际上将工厂模式提升到了基础设施层面。

代码实战：让我们看看真实的效果

光说不练假把式。为了让你直观地感受到两者的区别，让我们用 C# 风格的伪代码（这同样适用于 Java 或 TypeScript）来展示一个日志记录的例子。

场景一：不使用任何模式（紧耦合）

首先，让我们看看“反面教材”。这是我们大多数人刚开始写代码时的样子：

// 这是一个直接依赖具体实现的日志服务
public class OrderService 
{
    private FileLogger _logger;

    public OrderService() 
    {
        // 问题：这里硬编码了具体的 FileLogger。
        // 如果我们想换成一个 DatabaseLogger，必须修改 OrderService 的代码！
        // 这也意味着如果我们想测试 OrderService，我们就必须写文件到硬盘。
        _logger = new FileLogger();
    }

    public void CreateOrder(string itemName) 
    {
        // 记录日志
        _logger.Log("正在创建订单: " + itemName);
        // 业务逻辑...
    }
}

这种写法虽然简单，但在面对变化时极其脆弱。让我们看看如何用工厂模式和依赖注入来改进它。

场景二：使用工厂模式（封装复杂性）

工厂模式通过封装对象创建逻辑来解决部分问题。我们引入一个 LoggerFactory 来决定创建哪种日志记录器。

// 1. 定义产品接口
public interface ILogger 
{
    void Log(string message);
}

// 2. 具体产品 A
public class FileLogger : ILogger 
{
    public void Log(string message) 
    {
        Console.WriteLine($"[文件日志 - {DateTime.Now}] {message}");
    }
}

// 3. 具体产品 B
public class DatabaseLogger : ILogger 
{
    public void Log(string message) 
    {
        Console.WriteLine($"[数据库日志] 将日志 ‘{message}‘ 写入数据库...");
    }
}

// 4. 工厂类：负责创建逻辑
public static class LoggerFactory 
{
    // 在现代实践中，这个配置可能来自环境变量或配置中心
    public static ILogger CreateLogger() 
    {
        var loggerType = Environment.GetEnvironmentVariable("LOGGER_TYPE");
        
        // 工厂模式的核心：根据条件决定创建哪个对象
        // 注意：这里可能会变得复杂，比如涉及对象池初始化
        if (loggerType == "DB") 
        {
            return new DatabaseLogger();
        }
        return new FileLogger();
    }
}

// 5. 客户端代码
public class OrderServiceWithFactory 
{
    private ILogger _logger;

    public OrderServiceWithFactory() 
    {
        // 注意：虽然我们解耦了具体的 Logger 类，
        // 但 OrderService 仍然依赖具体的 LoggerFactory。
        // 我们仍然在类内部“主动”创建依赖，只是创建的方式变了。
        _logger = LoggerFactory.CreateLogger();
    }

    public void CreateOrder(string itemName) 
    {
        _logger.Log($"工厂模式：正在创建订单 {itemName}");
    }
}

工厂模式的优点： 客户端不再需要知道 INLINECODEecd2dad3 或 INLINECODEe73dd61e 的具体实现细节。创建逻辑被集中管理。
工厂模式的局限： INLINECODE78dd8e8c 仍然需要知道去哪里找日志记录器（即调用 INLINECODE0ddc8f0d）。它们之间仍然存在某种程度的耦合，这被称为“对工厂的依赖”。

场景三：使用依赖注入（彻底解耦）

现在，让我们看看依赖注入是如何彻底解决这个问题的。

// 接口和具体类定义同上...

// 依赖注入的客户端代码
public class OrderServiceWithDI 
{
    private readonly ILogger _logger;

    // 关键点：我们在构造函数中“声明”我们需要一个 ILogger，
    // 但我们不是自己在内部创建它，而是等待别人把它传进来。
    // 这使得 OrderServiceWithDI 成为了一个“纯”业务逻辑类。
    public OrderServiceWithDI(ILogger logger) 
    {
        _logger = logger;
    }

    public void CreateOrder(string itemName) 
    {
        _logger.Log($"依赖注入：正在创建订单 {itemName}");
    }
}

// 程序的入口（Main 方法或 Composition Root）充当“注入器”的角色
public class Program 
{
    public static void Main(string[] args) 
    {
        // 1. 组合根：这里决定创建具体的实现
        // 在2026年的真实应用中，这部分通常由 DI 容器框架自动完成
        ILogger myLogger = new FileLogger();
        
        // 2. 将依赖“注入”到 OrderService 中
        var orderService = new OrderServiceWithDI(myLogger);
        
        // 3. 执行业务
        orderService.CreateOrder("机械键盘");
        
        // 如果我们想换成数据库日志，只需修改这里的注入即可，OrderService 代码一行不用改！
        // 这种特性对于 AI 辅助重构非常重要，AI 可以轻松识别这种松散耦合的结构。
    }
}

2026年深度解析：生成式 AI 时代的模式演变

现在我们已经掌握了基础知识，让我们结合当前最热门的 Agentic AI (自主智能体) 趋势，来看看这些模式是如何演变的。

协同工作：构建 AI 原生应用架构

在我们最近构建的一个基于 RAG (检索增强生成) 的企业级知识库项目中，我们面临了一个经典的挑战：系统需要在运行时根据用户的查询类型，动态选择不同的 LLM（大语言模型）提供商（例如 OpenAI、Claude 或本地 LLM）。

如果我们在业务逻辑中写死 new OpenAIClient()，那么当我们要切换模型时，就必须修改代码并重新部署。这违背了云原生的敏捷性原则。

我们的解决方案： 结合了 工厂模式 和 依赖注入 的混合架构。

• 抽象层: 定义了一个 ILLMProvider 接口。
• 工厂模式: 创建了一个 LLMProviderFactory。这个工厂负责处理复杂的创建逻辑，例如读取 API Key、初始化超时参数、设置重试策略。这些逻辑如果不封装，会污染我们的 DI 容器配置。
• 依赖注入: 我们将 INLINECODE35e7a90c 注入到了我们的 INLINECODEba24df3f（智能体编排器）中。

这样的架构让我们获得了极大的灵活性。比如，我们可以在配置文件中定义：“当用户是 VIP 时，使用 INLINECODE607b1cce，当用户是普通用户时，使用 INLINECODE8eae4074”。工厂在运行时根据上下文创建不同的实现，而 INLINECODEa354a343 根本不需要知道这些细节，它只知道调用 INLINECODE5dfa0b4e 方法。

AI 辅助开发与模式识别

当我们使用像 Cursor 或 GitHub Copilot 这样的 AI 编程助手时，依赖注入显得尤为重要。AI 模型在分析代码时，对于显式的依赖关系（如构造函数参数）理解得非常透彻。

如果你的代码是 DI 风格的，当你要求 AI：“帮我为 INLINECODE5f102c12 编写单元测试”时，AI 能迅速识别出它依赖于 INLINECODE581114c4，并自动生成一个 Mock 对象。相反，如果你的代码中到处都是 new DatabaseConnection()，AI 可能会感到困惑，或者生成不稳定的测试代码，因为它试图模拟那些本不应该被模拟的内部实现细节。

最佳实践提示： 在 2026 年，编写“对 AI 友好”的代码实际上就是编写“对人类友好”的代码——清晰、解耦、接口驱动。DI 正是这样一种模式。

性能优化与陷阱排查：在生产环境中踩过的坑

让我们来谈谈更实际的工程问题。模式选对了，性能却不一定好。让我们看看我们如何在生产环境中优化这些模式。

1. 依赖注入的“捕捉-22”：生命周期管理

很多新手在引入 DI 后，会发现内存占用飙升，甚至出现“多线程竞争”问题。这通常是因为搞错了生命周期。

• Transient (瞬时): 每次请求都创建新对象。轻量、无状态的服务（如 Controller）适合这个。
• Scoped (作用域): 在同一个 HTTP 请求（或消息处理）内共享实例。非常适合 DbContext（数据库上下文）。
• Singleton (单例): 整个应用程序生命周期只有一个实例。危险！ 如果你在 Singleton 中注入了一个 Scoped 或 Transient 服务，可能会引发“Captured Dependency”问题，导致数据库连接不释放或内存泄漏。

我们的经验： 在高并发场景下，尽量避免在 Singleton 服务中持有对 Scoped 服务的直接依赖。如果必须使用，请使用 IServiceScopeFactory 手动创建作用域，或者重新设计你的架构。

2. 工厂模式的性能陷阱：过度封装

不要为了使用模式而使用模式。如果你只是简单的 INLINECODEef231c5bINLINECODE800db69bListFactoryINLINECODE6ca2458fStringBuilderFactoryINLINECODE6bcd56d6StringBuilderINLINECODEd046ab35IPaymentGatewayINLINECODE10ab8e7dif-elseINLINECODE88ac9dcdswitchINLINECODEbfa9e039OldLib.CreateInstance()` 时，创建一个工厂类来封装这个“坏味道”，让你的现代代码保持整洁。

总结

通过这篇文章，我们深入探讨了依赖注入和工厂模式这两个重要的设计工具。让我们来回顾一下最重要的几点：

• 关注点分离： 工厂模式关注对象创建，而依赖注入关注依赖管理和控制反转。它们解决的是软件架构中不同层面的问题。
• 灵活性来源： 工厂模式通过封装创建逻辑提供灵活性；依赖注入通过运行时组装提供灵活性。
• 协同工作： 在现代软件开发中，它们通常不是非此即彼的竞争对手，而是合作伙伴。我们可以用工厂模式来构建复杂的对象，然后用依赖注入将这些对象传递给需要它们的消费者。
• 面向未来： 随着 AI 和云原生技术的发展，代码的可维护性和可测试性变得比以往任何时候都重要。掌握 DI 和工厂模式，是构建能适应未来变化的弹性系统的关键。

当你下次开始一个新的项目或重构旧代码时，不妨停下来思考一下：“我这里是需要控制对象的创建，还是需要解耦我的依赖？” 做出正确的选择，你的代码将会变得更加优雅、健壮且易于维护。希望这篇指南能为你提供清晰的方向，祝你编码愉快！