单一职责原则要求一个类只承担一个职责，即只有一个引起变化的原因。在Java中，应将不同功能如数据操作和报表生成分别封装到UserRepository和UserReportGenerator类中，使UserManager仅负责协调，从而提升可维护性、可读性、可测试性和复用性，避免因职责耦合导致的相互影响，同时需注意避免过度拆分，合理界定职责粒度。
单一职责原则（Single Responsibility Principle，简称SRP）是面向对象设计五大原则（SOLID）之一。在Java中理解这个原则，关键在于明确“一个类应该只有一个引起它变化的原因”。
什么是单一职责原则
单一职责原则指的是：一个类或模块应当仅有一个职责，也就是说，它应该只做一件事，并且做好这件事。如果一个类承担了多个职责，那么当其中一个职责发生变化时，可能会影响到其他职责的正常运行。
例如，有一个UserManager类，既负责用户信息的存储操作，又负责生成用户报表。这时候，数据访问逻辑和业务报表逻辑耦合在一起。一旦报表格式需要修改，就可能需要改动这个类，进而影响到用户管理功能。这说明它有两个变化原因：数据管理和报表生成，违反了SRP。
如何在Java中应用单一职责原则
通过拆分职责，将不同的功能交给不同的类来处理，可以有效提升代码的可维护性和可测试性。
立即学习“Java免费学习笔记（深入）”；
- 将数据操作封装到UserRepository类中
- 将报表生成逻辑放到独立的UserReportGenerator类中
- UserManager只负责协调这两个类完成高层业务流程
这样每个类都有清晰的边界，修改报表不会影响数据访问，反之亦然。
遵循SRP的好处
在Java项目中坚持单一职责原则，能带来以下几个明显优势：
- 提高可维护性：修改某个功能时，只需关注对应的类，降低出错风险
- 增强可读性：类名和方法名更准确地反映其用途，便于团队协作
- 利于单元测试：每个类职责单一，测试用例更聚焦，更容易覆盖所有场景
- 支持复用：职责分明的类更容易被其他模块引用
需要注意的地方
过度拆分也会带来问题。比如把每行代码都单独封装成一个类，会导致系统复杂度上升。关键是根据实际业务需求，识别出“职责”的合理粒度。通常可以从需求变更的频率来判断——如果两个功能总是因同一类需求而改变，它们可能属于同一个职责。
基本上就这些。在Java开发中，保持对类职责的关注，定期审视是否出现了“多功能合一”的情况，有助于写出更健壮、灵活的代码。
