设计模式七大原则 - 单一职责原则（Single Responsibility Principle， SRP）

单一职责原则（Single Responsibility Principle, SRP）

——设计模式七大原则的核心基础

---

一、定义与核心思想

1. 核心定义
   一个类或模块应仅有一个引起其变化的原因，即一个类应专注于单一功能或一组高相关性的任务。例如：

   • 图书馆系统中，Book 类仅管理书籍属性（书名、作者），而借阅操作由 Library 类负责。
   • 员工管理系统中，Employee 类处理员工信息，数据持久化操作由 EmployeeDAO 类完成。

2. 核心思想

   • 职责隔离：避免类承担多个不相关的功能（如混合数据存储与业务逻辑）。
   • 内聚性优先：类的职责越单一，代码越清晰、可维护性越高。

---

二、设计目标与优势

1. 核心目标

   • 降低耦合：不同职责的代码分离后，修改某一功能不会影响其他模块。
   • 提升复用性：职责单一的类更易被其他模块复用。

2. 优势

   • 简化维护：需求变更时，只需修改对应职责的类。
   • 增强可测试性：单一职责的类更容易编写单元测试。

---

三、优缺点分析

优点	缺点
1. 高内聚性：代码逻辑集中，易读性强。 2. 降低风险：职责分离后，修改影响范围可控。	1. 类数量增加：过度拆分可能导致类膨。 2. 设计复杂度：职责界限需经验判断，初学者易误判。

---

四、适用场景

1. 复杂业务逻辑
   • 如电商系统中，订单创建、支付、物流跟踪应拆分到不同类。
2. 频繁变更的需求
   • 用户权限管理模块中，权限分配与验证逻辑分离。
3. 高复用性需求
   • 工具类（如日期格式化、加密算法）需保证职责单一。

---

五、实现示例

1. 反例：混合职责的类

   // 不符合SRP的图片加载类（混合缓存与加载逻辑）  
   public class ChaoticImageLoader {  
       private LruCache<String, Bitmap> mImageCache;  
       private ExecutorService mExecutorService;  
       
       public void initCache() { /* 缓存初始化 */ }  
       public void loadImage() { /* 网络加载图片 */ }  
   }  
   

   问题：缓存逻辑与加载逻辑耦合，修改缓存策略可能影响加载功能。

2. 正例：职责拆分

   // 缓存管理类  
   public class ImageCacheManager {  
       private LruCache<String, Bitmap> mImageCache;  
       public void initCache() { /* 缓存初始化 */ }  
   }  
   
   // 图片加载类  
   public class ImageLoader {  
       private ExecutorService mExecutorService;  
       public void loadImage() { /* 网络加载图片 */ }  
   }  
   

   改进：职责分离后，修改缓存逻辑无需调整加载代码。

---

六、实际应用案例

1. Java集合框架
   • ArrayList 负责数据存储，迭代逻辑由 Iterator 接口实现。
2. Spring框架的事务管理
   • 业务逻辑类处理核心操作，事务控制由 @Transactional 注解委托给AOP模块。
3. Android图片加载库Glide
   • 缓存管理、图片解码、网络请求等功能模块职责分离。

---

七、总结与建议

1. 核心原则
   SRP是设计模式的基础，但需结合场景灵活应用：

   • 避免教条：小型项目可适度合并职责（如工具类）。
   • 经验判断：职责划分需根据功能相关性（如用户登录与注册可合并，但与权限管理分离）。

2. 与其他原则的协同

   • 开闭原则：通过SRP拆分职责后，更容易通过扩展实现功能新增。
   • 接口隔离原则：SRP的延伸，进一步细化接口职责。