单一职责原则要求一个类只因一个原因改变，即只负责一个明确的业务变化动因；应按“谁提修改需求”而非功能主题拆分类，通过组合委托协作，接受小而专的类以降低维护成本。
保持类的单一职责，核心是让一个类只因一个原因而改变。换句话说，它只做一件事，并且把这件事做到位。
明确识别职责边界
职责不是功能点的简单罗列，而是业务变化的驱动源。比如“保存用户”和“校验用户”看似都跟用户有关，但校验规则可能随风控策略调整，而保存逻辑可能因数据库迁移改动——这是两个独立的变化动因。
- 问自己：如果这个需求变了，会影响其他功能吗？
- 检查方法：同一类里是否混用了数据操作、日志、格式转换、权限判断等不同领域逻辑？
- 警惕“辅助方法”：如
saveUser()里顺手调用sendEmail()或writeLog()，往往就是职责越界信号。
按变化原因拆分类
不按“用户相关”这种宽泛主题归类，而按“谁会提修改需求”来切分。产品改校验规则？找UserValidator；运维要换日志框架？改LogService；DBA调优SQL？只动UserRepository。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
-
User：纯数据载体，只有字段和getter/setter -
UserRepository：只管增删改查，不碰业务规则 -
UserValidator：只做校验，不执行保存或通知 -
UserNotificationService：只负责发消息，不参与流程决策
合理使用组合与委托
拆分后，类之间靠组合协作，而不是把所有逻辑塞进一个类。例如用户注册流程：
立即学习“Java免费学习笔记（深入）”；
-
UserService.register()本身不写校验或保存代码 - 它调用
validator.isValid()和repository.save() - 这样，每个环节可独立替换、测试、复用
接受“小而专”的类数量增长
初学者常担心类太多难管理，但实际维护成本远低于一个2000行的“全能类”。IDE能快速跳转，包结构可按职责分层（如model、repository、validator），命名清晰（OrderPaymentProcessor比OrderService更准确）就能自然降低认知负担。
