本文深入解析Python中面向对象设计的单一职责原则（SRP），强调一个类应仅承担一项明确、不可再分的职责，其修改原因必须唯一；通过真实代码对比揭示常见反模式（如将认证、通知、日志、缓存混杂于同一类），并系统介绍如何在Python中自然践行SRP：用清晰的问题“这个类存在的唯一理由是什么？”驱动设计，将“顺便做的事”拆分为独立组件，善用组合而非继承扩展能力，并借助Protocol或ABC以轻量、灵活的协议契约替代臃肿的继承体系，最终让代码更易维护、测试和演进。

单一职责原则（SRP）要求一个类只负责一项职责，修改原因应该只有一个。在Python中践行这一原则，不是靠强制约束，而是通过清晰的职责划分、合理的类粒度和明确的接口边界来实现。

职责要能一句话说清

定义类之前，先自问：“这个类存在的唯一理由是什么？”答案应该简洁、具体、不含“和”“或”“同时”。比如：

• ✅ 用户认证器：验证用户名密码是否正确
• ❌ 用户管理器：验证登录 + 创建用户 + 发送欢迎邮件 + 记录日志

后者明显混杂了认证、业务创建、通知、审计四类职责。一旦登录逻辑变（如加短信校验），或邮件模板改，都得动这个类——违反SRP。

把“顺便做的事”拆成独立类或函数

常见信号：类里出现 send_email、log_action、save_to_cache 等与核心目标无关的方法。它们不该属于主业务类，而应抽离：

• 用专门的 EmailNotifier 处理通知
• 用 AuditLogger 或标准库 logging 做日志
• 用 CacheService 封装缓存逻辑

例如，原本臃肿的 UserManager 中的注册方法：

def register(self, username, password):
    user = User.create(username, password)
    self.send_welcome_email(user)  # 职责越界
    self.log_registration(user)     # 职责越界
    self.cache_user(user)           # 职责越界
    return user

重构后，注册只做注册：

def register(self, username, password):
    user = User.create(username, password)
    self.notifier.send_welcome(user)   # 交给 notifier
    self.logger.info(f"User {user.id} registered")  # 交给 logger
    self.cache.set(f"user:{user.id}", user)        # 交给 cache
    return user

善用组合，少用继承扩展职责

想给类增加新能力时，优先考虑“由谁来帮它完成”，而不是“让它自己学会做”。比如为订单增加支付能力：

• ❌ 继承 PaymentOrder(Order)：强耦合，且一个类又管订单结构又管支付流程
• ✅ 组合：Order 持有 payment_service: PaymentService，调用 self.payment_service.charge(...)

这样支付逻辑可单独测试、替换（如从支付宝换成微信）、打桩模拟，订单类依然只专注订单状态与数据。

接口/协议比父类更能表达职责边界

Python中用 typing.Protocol 或抽象基类（ABC）声明“需要什么能力”，比让类继承某个大父类更轻量、更聚焦。例如定义一个“可持久化”行为：

class Storable(Protocol):
    def save(self) -> None: ...
    def delete(self) -> None: ...
class User:
def init(self, name: str): ...
不继承任何基类，但满足 Storable 协议
def persist(item: Storable):
item.save()  # 只依赖协议，不关心具体类型

这避免了为满足单一职责而被迫塞进一个“万能基类”，也让每个类真正只承担自己那一份契约。

以上就是《Python面向对象设计原则：单一职责详解》的详细内容，更多关于的资料请关注golang学习网公众号！