Dependency Injection与非DI示例的差异解析及代码补充需求

我来用一个贴近实际的日志服务场景，把DI和非DI的代码补全，帮你直观get到二者的差异，再聊聊你关心的「强制」特性区别～

先看最常见的非DI写法：业务类内部直接创建依赖实例，完全把自己和某个具体依赖绑死了。

# 非DI版本
class ConsoleLogger:
    def log(self, message):
        print(f"Console Log: {message}")

class UserService:
    def __init__(self):
        # 重点：内部直接实例化依赖，耦合死了
        self.logger = ConsoleLogger()

    def create_user(self, username):
        # 核心业务逻辑
        print(f"正在创建用户: {username}")
        # 调用依赖的方法
        self.logger.log(f"用户 {username} 创建成功")

# 使用方式
user_service = UserService()
user_service.create_user("Alice")

非DI的问题： #

• 完全和ConsoleLogger硬耦合，如果想换成文件日志、数据库日志，必须修改UserService的__init__代码
• 测试时没法用Mock日志（比如想验证日志是否被调用，但不想真的打印到控制台），只能用真实的ConsoleLogger，测试灵活性极差

DI的核心是依赖外部注入，业务类只依赖抽象（接口/抽象类），不关心具体实现是谁，由外部把依赖传进来。

# DI版本
from abc import ABC, abstractmethod

# 第一步：定义抽象的Logger接口（依赖抽象而非具体实现）
class Logger(ABC):
    @abstractmethod
    def log(self, message):
        pass

# 第二步：写具体的日志实现
class ConsoleLogger(Logger):
    def log(self, message):
        print(f"Console Log: {message}")

class FileLogger(Logger):
    def log(self, message):
        with open("user_logs.txt", "a", encoding="utf-8") as f:
            f.write(f"File Log: {message}\n")

# 第三步：业务类通过构造函数接收依赖（注入）
class UserService:
    # 只依赖Logger抽象，不关心具体是控制台还是文件日志
    def __init__(self, logger: Logger):
        self.logger = logger

    def create_user(self, username):
        print(f"正在创建用户: {username}")
        self.logger.log(f"用户 {username} 创建成功")

# 使用方式1：注入控制台日志
console_logger = ConsoleLogger()
user_service = UserService(console_logger)
user_service.create_user("Alice")

# 使用方式2：换成文件日志，完全不用改UserService！
file_logger = FileLogger()
user_service = UserService(file_logger)
user_service.create_user("Bob")

DI的优势： #

• 完全解耦：UserService只知道有个Logger能打日志，不管具体怎么实现
• 测试友好：可以写个MockLogger注入进去，验证日志调用逻辑，不用依赖真实日志组件
• 灵活性拉满：换依赖实现只需要改注入的地方，业务代码完全不用动

这部分是你重点关心的，我拆解成两点说：

非DI的「强制」：内部绑定的强制限制 #

非DI模式下，依赖的创建是业务类内部强制绑定的，调用者没有任何选择权：

• 必须使用类内部硬编码的那个依赖实现（比如上面的UserService只能用ConsoleLogger）
• 如果要换依赖，只能修改业务类的源代码，相当于被类本身强制锁死了依赖选项

DI的「强制」：契约与规则的强制约束 #

DI的「强制」是正向的、利于架构的约束：

• 依赖契约强制：如果用接口注入，注入的依赖必须符合接口定义的方法规范，强制所有实现类遵守统一标准，避免依赖的随意性
• 外部注入强制：在成熟的DI框架（比如Spring、FastAPI的DI）中，可以通过注解/配置强制要求注入特定的依赖实例，调用者甚至不需要手动创建依赖，框架会自动完成注入，强制保证依赖的正确性和可用性
• 依赖倒置强制：DI天然推动「依赖倒置原则」，强制业务类依赖抽象（接口/抽象类）而非具体实现，从根源上避免了硬耦合的强制绑定

内容的提问来源于stack exchange，提问作者hmmm