Python类设计核心是单一职责，即每个类只做一件事并做好；职责边界指类应承担的行为与数据范围，需通过影响范围、存储替换成本和测试便捷性三问判断；常见越界行为包括模型类发HTTP请求、业务类生成HTML、硬编码日志监控等，应拆分服务、分离数据与展示、用装饰器或中间件解耦；可用Protocol或ABC声明依赖协议，优先组合而非继承以增强灵活性与可测性。
Python类设计的核心不是堆砌功能，而是让每个类只做一件事，并且把这件事做好。边界划不清，职责不明确，代码就会快速变得难以理解、测试和修改。
什么是类的职责边界
职责边界指的是一个类应该承担哪些行为、持有哪些数据，以及它不该碰哪些事。比如，一个User类负责管理用户身份信息（姓名、邮箱、密码哈希），但不该负责发邮件、连数据库或校验手机号格式——这些是其他类或函数的活。
判断边界是否合理，可以问三个问题：
- 这个类修改后，是否会影响其他不相关的业务逻辑？
- 如果要换一种存储方式（比如从MySQL换成Redis），需要改几个类？理想情况是只改1个数据访问类。
- 单元测试时，是否能用几行mock就覆盖全部行为？如果要启动Web服务、读配置、连第三方API才能测，说明职责太重。
常见越界行为与重构建议
以下是一些高频“破界”现象，附带轻量级重构方向：
- 在模型类里写HTTP请求：比如Order.pay()直接调用requests.post()。应拆出PaymentService类，由上层协调调用。
- 一个类既处理业务又生成前端HTML：如ReportGenerator.render_html()。应分离为ReportDataBuilder（纯数据） + 模板引擎（Jinja等）。
- 把日志、监控、事务控制硬编码进业务方法：比如每个方法开头都有logger.info(...)和db.transaction()。应通过装饰器、上下文管理器或AOP风格中间件统一注入。
用协议和接口辅助边界表达
Python虽无interface关键字，但可用typing.Protocol或抽象基类（ABC）显式声明“这里需要什么能力”，而不是“这里要用哪个具体类”。例如：
定义一个Notifier协议，只要对象有send(self, message: str)方法就算符合；EmailNotifier、SmsNotifier各自实现，业务类只依赖协议——这样边界清晰，替换成本趋近于零。
协作关系比继承更能守住边界
优先用组合（has-a）而非继承（is-a）。比如不要让AdminUser继承User再塞一堆管理权限逻辑，而应让AdminUser持有一个PermissionChecker实例。这样权限策略可单独测试、独立演进，User类也保持干净。
组合还天然支持运行时替换：同一份用户数据，测试时注入MockPermissionChecker，生产时换真实实现，无需改任何业务代码。
