SOLID原则在Python中的实践：写出可维护的优雅代码

摘要

1 引言：为什么Python开发者更需要SOLID原则

1.1 Python的动态特性是一把双刃剑

1.2 SOLID原则的Python化解读

2 单一职责原则（SRP）：专注的力量

2.1 SRP核心理解：变更的理由是关键

2.2 实战：用户注册流程的重构

2.3 SRP带来的架构收益

3 开闭原则（OCP）：扩展的艺术

3.1 OCP本质：用扩展代替修改

3.2 实战：多格式导出系统

3.3 Python协议：更灵活的OCP实现

3.4 OCP性能优化技巧

4 依赖倒置原则（DIP）：面向抽象编程

4.1 DIP核心：高层模块不应该依赖低层模块

4.2 实战：数据库访问层的依赖倒置

4.3 依赖注入的Pythonic实现

4.4 基于装饰器的依赖注入

5 企业级实战：电子商务订单系统

5.1 需求分析：复杂的业务场景

5.2 基于SOLID原则的架构设计

5.3 扩展性演示：添加新功能

6 性能优化与故障排查

6.1 SOLID架构的性能考量

6.2 常见问题与解决方案

7 总结与最佳实践

7.1 SOLID原则在Python中的特殊考量

7.2 何时应该（和不应该）应用SOLID

7.3 性能数据总结

官方文档与权威参考

摘要

本文深入探讨SOLID原则在Python开发中的实战应用，聚焦单一职责原则、开闭原则和依赖倒置原则三大核心。通过完整案例和架构流程图以及性能对比数据，揭示如何将经典设计原则与Python动态特性相结合，写出高内聚、低耦合的优雅代码。文章包含企业级应用场景、性能优化技巧和故障排查指南，为Python开发者提供从理论到实践的完整解决方案。

1 引言：为什么Python开发者更需要SOLID原则

在我多年的Python开发生涯中，见过太多"面条代码"（spaghetti code）的悲剧。记得曾接手一个快速迭代的创业公司项目，初期为了赶进度，将业务逻辑、数据持久化和API处理全部塞进一个5000行的模块中。结果当业务增长时，每次修改都像在走钢丝，测试覆盖率不足35%，bug数量随代码行数指数级增长。

1.1 Python的动态特性是一把双刃剑

Python的动态类型和鸭子类型让开发变得灵活高效，但同时也容易导致架构混乱。与Java等静态语言不同，Python没有编译器帮助进行架构约束，这就更需要设计原则来指导代码组织。

# 反例：典型的"上帝类"（God Class） class BusinessProcessor: def __init__(self): self.db_connection = None self.http_client = None self.config = {} def validate_user(self, user_data): # 验证逻辑 pass def save_to_database(self, user_data): # 数据库操作 pass def send_email(self, user_email): # 邮件发送 pass def generate_report(self, data): # 报告生成 pass def handle_api_request(self, request): # 处理HTTP请求 pass

上述代码虽然功能完整，但违反了单一职责原则，导致类有多个变更理由，难以维护和测试。

1.2 SOLID原则的Python化解读

SOLID原则最初针对静态类型语言提出，在Python中需要重新诠释：

S（单一职责）：一个类应该只有一个变更的理由
O（开闭原则）：对扩展开放，对修改关闭，利用Python的鸭子类型和协议
L（里氏替换）：子类应该可以替换父类而不破坏程序，Python更注重行为兼容性
I（接口隔离）：客户端不应被迫依赖不需要的方法，Python通过抽象基类和协议实现
D（依赖倒置）：依赖抽象而非具体实现，Python通过依赖注入实现

下面通过一个架构演进图展示SOLID原则如何提升代码质量：

2 单一职责原则（SRP）：专注的力量

2.1 SRP核心理解：变更的理由是关键

SRP并非简单地"一个类只做一件事"，而是一个类应该只有一个引起它变化的原因。这个细微差别很重要，它关注的是变更的驱动力。

在我经历的一个电商项目中，订单处理类最初承担了验证、计算、持久化、通知等职责。当促销策略变化时，需要修改这个类；当支付方式增加时，又需要修改这个类。这种设计导致变更耦合，每次修改都可能引入意外bug。

2.2 实战：用户注册流程的重构

下面通过一个用户注册案例，展示SRP的实际应用：

# 违反SRP的版本 class UserRegistration: """违反SRP的用户注册类""" def __init__(self): self.db = Database() self.email_sender = EmailSender() self.validator = Validator() def register_user(self, user_data): # 1. 验证输入 if not self.validator.validate_email(user_data['email']): raise ValueError("Invalid email") if not self.validator.validate_password(user_data['password']): raise ValueError("Invalid password") # 2. 业务逻辑检查 if self.db.user_exists(user_data['email']): raise ValueError("User already exists") # 3. 创建用户 user = self._create_user_object(user_data) # 4. 保存到数据库 self.db.save_user(user) # 5. 发送欢迎邮件 self.email_sender.send_welcome_email(user.email) # 6. 记录日志 self._log_registration(user) return user def _create_user_object(self, user_data): # 创建用户对象逻辑 pass def _log_registration(self, user): # 记录日志逻辑 pass

这个类有至少4个变更理由：验证规则变化、存储方式变化、邮件模板变化、日志策略变化。

重构后的SRP合规版本：

# 遵守SRP的版本 class UserValidator: """专职验证""" def validate_registration_data(self, user_data): if not self.validate_email(user_data['email']): return False, "Invalid email" if not self.validate_password(user_data['password']): return False, "Invalid password" return True, "Valid" def validate_email(self, email): # 邮箱验证逻辑 return "@" in email def validate_password(self, password): # 密码验证逻辑 return len(password) >= 8 class UserRepository: """专职数据持久化""" def __init__(self, db): self.db = db def save_user(self, user): return self.db.save_user(user) def user_exists(self, email): return self.db.user_exists(email) class EmailService: """专职邮件发送""" def send_welcome_email(self, email): # 发送欢迎邮件逻辑 pass class RegistrationLogger: """专职日志记录""" def log_registration(self, user): # 记录注册日志 pass # 高层协调类 class UserRegistrationService: """协调用户注册流程，符合SRP""" def __init__(self, validator, repository, email_service, logger): self.validator = validator self.repository = repository self.email_service = email_service self.logger = logger def register_user(self, user_data): # 专职协调，不涉及具体实现 is_valid, message = self.validator.validate_registration_data(user_data) if not is_valid: raise ValueError(message) if self.repository.user_exists(user_data['email']): raise ValueError("User already exists") user = User(**user_data) self.repository.save_user(user) self.email_service.send_welcome_email(user.email) self.logger.log_registration(user) return user

2.3 SRP带来的架构收益

通过SRP重构后，代码的可测试性和可维护性显著提升：

# 测试变得简单 def test_user_validator(): validator = UserValidator() is_valid, msg = validator.validate_registration_data({ 'email': 'test@example.com', 'password': 'weak' }) assert not is_valid assert "password" in msg def test_user_registration_service(): # 可以使用Mock对象进行测试 mock_validator = Mock() mock_repository = Mock() mock_email = Mock() mock_logger = Mock() service = UserRegistrationService( mock_validator, mock_repository, mock_email, mock_logger ) # 测试逻辑...

性能考量：虽然类数量增加，但现代Python的导入优化和方法缓存使得额外的抽象层开销可以忽略不计。在真实项目中，这种架构清晰度的提升远远超过微小的性能开销。

3 开闭原则（OCP）：扩展的艺术

3.1 OCP本质：用扩展代替修改

开闭原则要求软件实体对扩展开放，对修改关闭。在Python中，这意味着当需求变化时，我们应该添加新代码而不是修改已有代码。

在我参与的一个报表生成系统中，最初只支持PDF导出。当需要添加Excel导出时，如果直接修改原有PDF生成类，就会违反OCP。正确的做法是通过继承或组合来扩展功能。

3.2 实战：多格式导出系统

from abc import ABC, abstractmethod from typing import List, Dict, Any # 违反OCP的实现 class ReportExporter: """违反OCP的报表导出器""" def export(self, data: List[Dict], format_type: str): if format_type == "pdf": return self._export_pdf(data) elif format_type == "excel": return self._export_excel(data) elif format_type == "csv": return self._export_csv(data) else: raise ValueError(f"Unsupported format: {format_type}") def _export_pdf(self, data): # PDF导出逻辑 return f"PDF: {data}" def _export_excel(self, data): # Excel导出逻辑 return f"Excel: {data}" def _export_csv(self, data): # CSV导出逻辑 return f"CSV: {data}"

每添加一种新格式，都需要修改export方法和ReportExporter类，违反了OCP。

符合OCP的重构：

# 定义抽象接口 class ExportStrategy(ABC): """导出策略抽象基类""" @abstractmethod def export(self, data: List[Dict]) -> str: pass # 具体策略实现 class PDFExportStrategy(ExportStrategy): def export(self, data: List[Dict]) -> str: # PDF导出逻辑 return f"PDF: {data}" class ExcelExportStrategy(ExportStrategy): def export(self, data: List[Dict]) -> str: # Excel导出逻辑 return f"Excel: {data}" class CSVExportStrategy(ExportStrategy): def export(self, data: List[Dict]) -> str: # CSV导出逻辑 return f"CSV: {data}" # 支持新格式只需添加新策略，不需要修改现有代码 class JSONExportStrategy(ExportStrategy): def export(self, data: List[Dict]) -> str: import json return json.dumps(data) # 上下文类 class ReportExporter: """符合OCP的报表导出器""" def __init__(self): self._strategies = {} self._register_default_strategies() def _register_default_strategies(self): self._strategies = { "pdf": PDFExportStrategy(), "excel": ExcelExportStrategy(), "csv": CSVExportStrategy() } def register_strategy(self, format_type: str, strategy: ExportStrategy): """注册新的导出策略，支持扩展""" self._strategies[format_type] = strategy def export(self, data: List[Dict], format_type: str) -> str: if format_type not in self._strategies: raise ValueError(f"Unsupported format: {format_type}") strategy = self._strategies[format_type] return strategy.export(data) # 使用示例 exporter = ReportExporter() # 可以轻松扩展新格式，无需修改现有代码 exporter.register_strategy("json", JSONExportStrategy()) # 使用各种格式导出 data = [{"name": "Alice", "value": 100}, {"name": "Bob", "value": 200}] pdf_result = exporter.export(data, "pdf") json_result = exporter.export(data, "json")

3.3 Python协议：更灵活的OCP实现

Python 3.8+引入了协议（Protocol），提供了结构子类型支持，让OCP实现更加灵活：

from typing import Protocol, List, Dict # 使用协议定义接口 class ExportStrategy(Protocol): def export(self, data: List[Dict]) -> str: ... # 任何实现了export方法的类都自动符合协议 class XMLExportStrategy: """不需要显式继承，只要实现export方法即可""" def export(self, data: List[Dict]) -> str: # XML导出逻辑 return f"<data>{data}</data>" class CustomExporter: def __init__(self, strategy: ExportStrategy): self.strategy = strategy def execute_export(self, data: List[Dict]) -> str: return self.strategy.export(data) # 使用协议，兼容性更好 exporter = CustomExporter(XMLExportStrategy()) result = exporter.execute_export([{"test": "data"}])

这种鸭子类型的方式让OCP在Python中更加自然和灵活。

下面的流程图展示了基于策略模式的OCP实现架构：

3.4 OCP性能优化技巧

虽然策略模式增加了灵活性，但可能引入性能开销。以下是优化建议：

# 使用__slots__减少内存开销 class PDFExportStrategy: __slots__ = ['config'] # 固定属性列表，减少内存使用 def __init__(self, config=None): self.config = config or {} def export(self, data): # 导出逻辑 pass # 使用函数代替类（轻量级策略） def pdf_export_strategy(data, config=None): """函数式策略，性能更好""" return f"PDF: {data}" class OptimizedReportExporter: """优化性能的导出器""" def __init__(self): self._strategies = { "pdf": pdf_export_strategy, # ... 其他策略 } def export(self, data, format_type): strategy = self._strategies.get(format_type) if strategy is None: raise ValueError(f"Unsupported format: {format_type}") # 直接调用函数，避免方法查找开销 return strategy(data)

4 依赖倒置原则（DIP）：面向抽象编程

4.1 DIP核心：高层模块不应该依赖低层模块

DIP是SOLID中最难理解但最重要的原则。它要求：

高层模块不应该依赖低层模块，两者都应该依赖抽象
抽象不应该依赖细节，细节应该依赖抽象

在Python中，这意味着我们应该依赖抽象基类或协议，而不是具体实现。

4.2 实战：数据库访问层的依赖倒置

下面通过一个典型的数据访问案例展示DIP的应用：

# 违反DIP的实现 class MySQLDatabase: """低层模块：MySQL具体实现""" def connect(self, host, user, password, database): # MySQL连接逻辑 print("Connecting to MySQL...") return MySQLConnection() def query(self, sql): # 执行查询 print(f"Executing MySQL query: {sql}") return [{"id": 1, "name": "John"}] def close(self): # 关闭连接 print("Closing MySQL connection") # 高层模块直接依赖低层模块 class UserService: """违反DIP：直接依赖MySQLDatabase""" def __init__(self): # 直接依赖具体实现 self.db = MySQLDatabase() self.connection = self.db.connect( "localhost", "user", "password", "mydb" ) def get_users(self): return self.db.query("SELECT * FROM users") def __del__(self): self.db.close()

这种设计的問題：当需要切换数据库时（如从MySQL切换到PostgreSQL），必须修改UserService类。

符合DIP的重构：

from abc import ABC, abstractmethod from typing import List, Dict, Any # 抽象层（高层模块依赖的抽象） class Database(ABC): """抽象数据库接口""" @abstractmethod def connect(self, **kwargs): pass @abstractmethod def query(self, sql: str) -> List[Dict[str, Any]]: pass @abstractmethod def close(self): pass # 低层模块实现抽象 class MySQLDatabase(Database): """MySQL具体实现，依赖抽象""" def connect(self, **kwargs): print("Connecting to MySQL...") return MySQLConnection() def query(self, sql: str) -> List[Dict[str, Any]]: print(f"Executing MySQL query: {sql}") return [{"id": 1, "name": "John"}] def close(self): print("Closing MySQL connection") class PostgreSQLDatabase(Database): """PostgreSQL具体实现，依赖抽象""" def connect(self, **kwargs): print("Connecting to PostgreSQL...") return PostgreSQLConnection() def query(self, sql: str) -> List[Dict[str, Any]]: print(f"Executing PostgreSQL query: {sql}") return [{"id": 1, "name": "John", "postgres_specific": True}] def close(self): print("Closing PostgreSQL connection") # 高层模块依赖抽象 class UserService: """符合DIP：依赖Database抽象""" def __init__(self, db: Database): # 依赖注入，接收抽象接口 self.db = db self.connection = self.db.connect() def get_users(self) -> List[Dict[str, Any]]: return self.db.query("SELECT * FROM users") def get_user_by_id(self, user_id: int) -> Dict[str, Any]: result = self.db.query(f"SELECT * FROM users WHERE id = {user_id}") return result[0] if result else {} def close(self): self.db.close() # 依赖注入容器（简单实现） class DIContainer: """简单的依赖注入容器""" def __init__(self): self._dependencies = {} def register(self, abstract, concrete): self._dependencies[abstract] = concrete def resolve(self, abstract): if abstract not in self._dependencies: raise ValueError(f"Dependency not registered: {abstract}") return self._dependencies[abstract]() # 配置和使用 def configure_dependencies(): """依赖配置""" container = DIContainer() # 注册抽象和具体实现的映射 # 切换数据库只需修改这一行 container.register(Database, MySQLDatabase) # 或 PostgreSQLDatabase return container # 使用依赖注入 container = configure_dependencies() db = container.resolve(Database) user_service = UserService(db) users = user_service.get_users() user_service.close()

4.3 依赖注入的Pythonic实现

Python社区有多种依赖注入方式，以下是几种常见模式：

# 方法1：构造函数注入（最常用） class UserService: def __init__(self, db: Database, email_sender: EmailSender): self.db = db self.email_sender = email_sender # 方法2：设置方法注入 class UserService: def set_database(self, db: Database): self.db = db def set_email_sender(self, email_sender: EmailSender): self.email_sender = email_sender # 方法3：上下文管理器注入（Pythonic方式） class DatabaseContext: def __init__(self, db: Database): self.db = db def __enter__(self): self.connection = self.db.connect() return self def __exit__(self, exc_type, exc_val, exc_tb): self.db.close() def get_users(self): return self.db.query("SELECT * FROM users") # 使用上下文管理器，自动管理资源 with DatabaseContext(MySQLDatabase()) as db_context: users = db_context.get_users()

下面的序列图展示了依赖倒置原则下的对象协作关系：

4.4 基于装饰器的依赖注入

对于Web应用等场景，可以使用装饰器简化依赖注入：

import functools from typing import Dict, Any # 简单的依赖注入装饰器 def inject_dependencies(func): """依赖注入装饰器""" @functools.wraps(func) def wrapper(*args, **kwargs): # 解析依赖 dependencies = resolve_dependencies() # 注入依赖 for dep_name, dep_instance in dependencies.items(): if dep_name not in kwargs: kwargs[dep_name] = dep_instance return func(*args, **kwargs) return wrapper def resolve_dependencies() -> Dict[str, Any]: """解析依赖""" return { 'db': MySQLDatabase(), 'email_sender': SMTPEmailSender(), 'logger': FileLogger() } # 使用装饰器自动注入依赖 class UserController: @inject_dependencies def create_user(self, user_data, db=None, email_sender=None, logger=None): # 方法参数自动注入 user = db.save_user(user_data) email_sender.send_welcome_email(user.email) logger.log(f"User created: {user.id}") return user # 使用 controller = UserController() user = controller.create_user({"name": "Alice", "email": "alice@example.com"})

5 企业级实战：电子商务订单系统

5.1 需求分析：复杂的业务场景

假设我们正在开发一个电子商务订单系统，需要处理：

订单创建和验证
库存检查和管理
支付处理（多种支付方式）
订单状态跟踪
通知发送（邮件、短信）

5.2 基于SOLID原则的架构设计

from abc import ABC, abstractmethod from typing import List, Dict, Any from datetime import datetime import uuid # 领域模型 class Order: def __init__(self, order_id: str, items: List[Dict], total: float): self.order_id = order_id self.items = items self.total = total self.status = "created" self.created_at = datetime.now() # 抽象层定义 class OrderValidator(ABC): """订单验证抽象""" @abstractmethod def validate(self, order: Order) -> bool: pass class InventoryManager(ABC): """库存管理抽象""" @abstractmethod def check_stock(self, product_id: str, quantity: int) -> bool: pass @abstractmethod def reserve_stock(self, product_id: str, quantity: int) -> bool: pass class PaymentProcessor(ABC): """支付处理抽象""" @abstractmethod def process_payment(self, order: Order, payment_method: str) -> bool: pass class Notifier(ABC): """通知抽象""" @abstractmethod def send_notification(self, recipient: str, message: str) -> bool: pass # 具体实现 class BasicOrderValidator(OrderValidator): """基本订单验证""" def validate(self, order: Order) -> bool: if not order.items: return False, "Order must have items" if order.total <= 0: return False, "Order total must be positive" return True, "Valid" class DatabaseInventoryManager(InventoryManager): """数据库库存管理""" def check_stock(self, product_id: str, quantity: int) -> bool: # 检查库存逻辑 return True # 简化实现 def reserve_stock(self, product_id: str, quantity: int) -> bool: # 预留库存逻辑 return True class StripePaymentProcessor(PaymentProcessor): """Stripe支付处理""" def process_payment(self, order: Order, payment_method: str) -> bool: # Stripe支付逻辑 print(f"Processing payment of ${order.total} via Stripe") return True class EmailNotifier(Notifier): """邮件通知""" def send_notification(self, recipient: str, message: str) -> bool: print(f"Sending email to {recipient}: {message}") return True # 高层业务服务 class OrderService: """订单服务，符合SOLID原则""" def __init__(self, validator: OrderValidator, inventory_manager: InventoryManager, payment_processor: PaymentProcessor, notifier: Notifier): self.validator = validator self.inventory_manager = inventory_manager self.payment_processor = payment_processor self.notifier = notifier def create_order(self, order_data: Dict, payment_method: str) -> Order: # 1. 创建订单对象 order = Order( order_id=str(uuid.uuid4()), items=order_data['items'], total=order_data['total'] ) # 2. 验证订单（SRP：验证职责分离） is_valid, message = self.validator.validate(order) if not is_valid: raise ValueError(f"Order validation failed: {message}") # 3. 检查库存（SRP：库存管理分离） for item in order.items: if not self.inventory_manager.check_stock(item['product_id'], item['quantity']): raise ValueError(f"Insufficient stock for product {item['product_id']}") # 4. 预留库存 for item in order.items: self.inventory_manager.reserve_stock(item['product_id'], item['quantity']) # 5. 处理支付（SRP：支付处理分离） payment_success = self.payment_processor.process_payment(order, payment_method) if not payment_success: # 释放预留库存 self._release_reserved_stock(order.items) raise ValueError("Payment processing failed") # 6. 更新订单状态 order.status = "completed" # 7. 发送通知（SRP：通知职责分离） self.notifier.send_notification( order_data['customer_email'], f"Order {order.order_id} completed successfully" ) return order def _release_reserved_stock(self, items: List[Dict]): """释放预留库存""" for item in items: # 库存释放逻辑 pass # 依赖配置 def create_order_service() -> OrderService: """创建订单服务（依赖配置）""" validator = BasicOrderValidator() inventory_manager = DatabaseInventoryManager() payment_processor = StripePaymentProcessor() notifier = EmailNotifier() return OrderService(validator, inventory_manager, payment_processor, notifier) # 使用示例 def main(): order_service = create_order_service() order_data = { 'items': [ {'product_id': 'prod1', 'quantity': 2, 'price': 50}, {'product_id': 'prod2', 'quantity': 1, 'price': 30} ], 'total': 130, 'customer_email': 'customer@example.com' } try: order = order_service.create_order(order_data, "credit_card") print(f"Order created successfully: {order.order_id}") except ValueError as e: print(f"Order creation failed: {e}") if __name__ == "__main__": main()

5.3 扩展性演示：添加新功能

当需要添加新功能时，SOLID架构的优势显现：

# 添加新的支付方式（符合OCP） class PayPalPaymentProcessor(PaymentProcessor): """PayPal支付处理，扩展而非修改""" def process_payment(self, order: Order, payment_method: str) -> bool: print(f"Processing payment of ${order.total} via PayPal") return True # 添加新的验证规则（符合OCP） class FraudDetectionValidator(OrderValidator): """欺诈检测验证器""" def __init__(self, base_validator: OrderValidator): self.base_validator = base_validator def validate(self, order: Order) -> bool: # 先执行基础验证 is_valid, message = self.base_validator.validate(order) if not is_valid: return False, message # 欺诈检测逻辑 if order.total > 10000: # 大额订单检查 return False, "Large order requires manual review" return True, "Valid" # 更新依赖配置 def create_enhanced_order_service() -> OrderService: """创建增强版订单服务""" base_validator = BasicOrderValidator() validator = FraudDetectionValidator(base_validator) # 装饰器模式 inventory_manager = DatabaseInventoryManager() payment_processor = PayPalPaymentProcessor() # 切换支付方式 notifier = EmailNotifier() return OrderService(validator, inventory_manager, payment_processor, notifier)

6 性能优化与故障排查

6.1 SOLID架构的性能考量

虽然SOLID原则提高了代码质量，但可能引入性能开销。以下是一些优化策略：

1. 延迟加载优化

class LazyDependency: """延迟加载依赖""" def __init__(self, factory): self._factory = factory self._instance = None def __getattr__(self, name): if self._instance is None: self._instance = self._factory() return getattr(self._instance, name) class OptimizedOrderService: """优化性能的订单服务""" def __init__(self, db_factory, email_factory): # 延迟加载重量级依赖 self._db = LazyDependency(db_factory) self._email_sender = LazyDependency(email_factory) @property def db(self): return self._db @property def email_sender(self): return self._email_sender

2. 缓存优化

from functools import lru_cache class CachedOrderService: """带缓存的订单服务""" def __init__(self, order_repository): self.order_repository = order_repository @lru_cache(maxsize=1000) def get_order(self, order_id: str) -> Order: """缓存订单查询结果""" return self.order_repository.find_by_id(order_id)

6.2 常见问题与解决方案

问题1：过度工程化

# 反例：不必要的抽象 class AbstractOrderCreator(ABC): @abstractmethod def create(self): pass class OrderCreator(AbstractOrderCreator): def create(self): pass # 正例：简单函数 def create_order(order_data): # 直接实现 pass

问题2：依赖注入复杂性

# 使用简单的依赖注入容器 class SimpleContainer: _instances = {} @classmethod def register(cls, abstract, implementation): cls._instances[abstract] = implementation @classmethod def resolve(cls, abstract): return cls._instances.get(abstract) # 注册依赖 SimpleContainer.register(Database, MySQLDatabase) SimpleContainer.register(EmailSender, SMTPEmailSender) # 解析使用 db = SimpleContainer.resolve(Database)