一个类应该只有一个引起它变化的原因，即只承担一项职责，通过将用户数据存储、邮件发送和报表生成等功能分离到不同的类中，如employeerepository、emailservice和reportgenerator，确保每个类职责单一，从而提升代码的可维护性、可测试性和可扩展性。
设计良好的类结构是编写可维护、可扩展代码的基础，而单一职责原则（Single Responsibility Principle, SRP）是实现这一目标的核心。它属于面向对象设计的SOLID原则之一，强调：一个类应该只有一个引起它变化的原因。换句话说，一个类只负责一项职责。
下面从实践角度，说明如何通过单一职责原则来设计更清晰的类结构。
什么是单一职责原则？
单一职责原则并不只是“一个类只做一件事”这么简单，它的本质是关注点分离。如果一个类承担了多个不相关的功能，那么当其中一个功能需要修改时，可能会影响其他功能，增加出错风险，也使得测试和维护变得困难。
例如，一个
User
类如果既负责用户数据的存储，又负责发送邮件，还负责生成报表，那么：
- 修改邮件模板会影响用户数据逻辑；
- 调整报表格式可能需要重新测试用户保存功能；
- 单元测试变得复杂，难以隔离。
这说明这个类职责过多，违反了SRP。
如何识别类的职责是否单一？
判断一个类是否符合单一职责，可以问以下几个问题：
- 这个类的每个方法是否都服务于同一个目的？
- 如果需求变化，会因为几种不同类型的原因修改这个类？
- 是否可以为这个类写出一个简洁、不包含“和”“或”的职责描述？
比如：
✅ 良好描述：“UserRepository 负责用户数据的持久化操作。”
❌ 不良描述：“UserService 负责用户注册、发送欢迎邮件和记录日志。”
后者明显包含多个职责，应拆分。
实践中的拆分策略
当发现一个类职责过多时，可以通过以下方式重构：
-
按功能边界拆分
将不同的功能移到独立的类中。例如：-
UserManager
：处理用户业务逻辑（如注册、权限校验）
-
EmailService
：负责发送邮件
-
Logger
：负责记录操作日志
-
-
引入服务类或工具类
将原本在实体类中的非核心逻辑提取出去。例如，不要在Order
类中写发送发票邮件的逻辑，而应由
InvoiceService
或
NotificationService
来处理。
-
使用组合代替臃肿的单一类
通过组合多个小类来完成复杂任务。例如：
class OrderProcessor { private PaymentService paymentService; private InventoryService inventoryService; private NotificationService notificationService; public void process(Order order) { paymentService.charge(order); inventoryService.reduceStock(order); notificationService.sendConfirmation(order); } }
每个服务只关心自己的职责，
OrderProcessor
协调流程，但不实现具体细节。
常见误区与注意事项
-
不要过度拆分
拆分是为了清晰，不是为了数量。比如把每个 getter 和 setter 都拆成一个类，是荒谬的。关键看“变化的原因”是否不同。 -
职责粒度要合理
一个类负责“用户认证”是可以接受的，但若把“用户名验证”“密码加密”“登录日志”全放一起，就可能需要进一步分离。 -
关注变化频率
如果两个功能总是同时修改，说明它们属于同一职责；如果经常一个变另一个不变，就应该拆开。 -
配合依赖注入使用效果更佳
拆分后的类通过依赖注入组合，便于替换和测试。例如在spring中用@Service
注解管理各个职责类。
实际例子：重构一个“坏味道”类
原始代码：
class Employee { public void save() { /* 保存到数据库 */ } public void sendPromotionEmail() { /* 发送升职邮件 */ } public String generateReport() { /* 生成员工报告 */ } }
问题：三个完全不同的职责。
重构后：
class Employee { /* 只包含属性和业务方法 */ } class EmployeeRepository { public void save(Employee emp) { /* 持久化 */ } } class EmailService { public void sendPromotionEmail(Employee emp) { /* 发邮件 */ } } class ReportGenerator { public String generateReport(Employee emp) { /* 生成报告 */ } }
现在每个类只做一件事，修改数据库逻辑不会影响邮件功能。
基本上就这些。单一职责原则看似简单，但在日常开发中容易被忽视。关键是养成“这个类为什么会被修改”的思考习惯。只要持续关注职责边界，类结构自然会变得更清晰、更灵活。
