单职责原则要求一个类只承担一个职责，即仅有一个引起变化的原因。例如UserManager类若同时处理用户校验和数据库保存，则违反该原则；应将其拆分为UserValidator和UserRepository两个类，分别专注校验与持久化。通过按功能拆分、关注点分离和高内聚低耦合的设计，可使类更清晰、易维护。实际开发中可通过类名是否明确、方法是否服务于同一目标来判断是否符合该原则。
在Java中，类的职责指的是一个类应该封装与其相关的行为和数据，并且只负责一个明确的功能或业务逻辑。理解这一点，是掌握面向对象设计的关键。单职责原则（Single Responsibility Principle, SRP）正是对这一思想的规范表达：一个类应该只有一个引起它变化的原因。
什么是单职责原则
单职责原则是SOLID五大设计原则中的第一个。它强调：一个类应当仅有一个职责，也就是说，它的功能应当足够单一，所有的方法和属性都应围绕这个核心职责展开。
如果一个类承担了多个职责，那么当其中一个职责发生变化时，可能会影响到其他职责的正常运行，从而增加维护成本和出错风险。
举例说明：假设有一个UserManager类，既负责用户信息的校验，又负责将用户数据保存到数据库：
立即学习“Java免费学习笔记（深入）”；
class UserManager {
public boolean validateUser(User user) {
// 校验逻辑
}
public void saveToDatabase(User user) {
// 数据库操作
}
}
这个类就违反了单职责原则——它同时承担了“校验”和“持久化”两个职责。一旦校验规则改变或数据库结构调整，都需要修改这个类，容易引发问题。
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
如何体现单职责原则
要让类的设计符合单职责原则，可以从以下几个方面入手：
-
按功能拆分类：将不同的职责分离到不同的类中。比如上面的例子可以拆分为
UserValidator和UserRepository。 - 关注点分离：确保每个类只处理一个层面的问题，例如业务逻辑、数据访问、日志记录等应分别由不同类负责。
- 高内聚低耦合：职责单一的类更容易实现内部高度聚合，同时减少与其他类之间的依赖关系。
重构后的代码可能如下：
class UserValidator {
public boolean isValid(User user) {
// 只做校验
}
}
class UserRepository {
public void save(User user) {
// 只负责存储
}
}
这样，每个类都只专注于自己的任务，修改其中一个不会轻易影响另一个。
实际开发中的应用建议
在日常编码中，可以通过以下方式判断类是否遵循单职责原则：
- 看类名是否清晰表达了唯一职责，如
OrderProcessor比OrderHelper更具体。 - 检查类中的方法是否都在服务同一个目标。
- 思考“如果需求变了，哪些方法会一起改？”如果多个不相关的部分总是一起变，说明职责混杂。
使用设计模式如策略模式、观察者模式等，也有助于将职责分散到合适的类中。
基本上就这些。单职责原则看似简单，但在复杂系统中容易被忽视。坚持这一原则，能让Java类更清晰、可读、可测试、易于维护。
