解锁设计模式：单一职责原则，代码整洁之道-CSDN博客

在软件开发的世界里，也有这样一个至关重要的原则，让程序结构清晰、易于维护，它就是单一职责原则（Single Responsibility Principle，简称 SRP）。这个原则看似简单，却蕴含着强大的力量，是设计模式的 “基石”，深刻影响着代码的质量和可扩展性。接下来，就让我们一起深入探索它的奥秘 🔍 。

二、单一职责原则是什么

2.1 定义解析

单一职责原则，从字面意思理解，就是一个类应该仅有一个引起它变化的原因。这里的 “职责”，可以简单理解为 “变化的原因”。用大白话来讲，一个类只干一件事，只对这一件事负责。比如，一个 “用户信息管理类”，它就只负责存储和管理用户的基本信息，像用户名、密码、联系方式等。而发送用户通知（比如注册成功通知、密码找回通知）的功能，就不应该由这个类来承担，因为这是另一个独立的职责，应该交给专门的 “通知发送类” 。

如果一个类承担了多个职责，就像一个人既要当厨师做饭，又要当服务员上菜，还要当收银员结账，一旦其中某一个职责发生变化，比如结账方式改变了，可能就会影响到做饭和上菜的流程。在代码里，这就表现为一个类的修改可能会导致其他不相关功能出现问题，增加了代码出错的风险和维护的难度。

2.2 职责边界探讨

虽然单一职责原则听起来很清晰，但在实际应用中，确定职责的边界可不容易。到底怎样才算 “单一职责” 呢🧐 这并没有一个绝对的标准，它往往取决于具体的业务场景和需求。

比如说，在一个简单的电商系统中，最初可能只有商品展示和下单功能。这时，我们可以把商品相关的操作，如获取商品信息、展示商品详情，以及下单操作都放在一个 “商品服务类” 中。因为在这个阶段，业务简单，这些功能紧密相关，放在一个类里不会有太大问题，也便于开发和维护。

但随着业务的发展，电商系统要增加商品库存管理、促销活动管理等功能。如果还把所有这些功能都放在 “商品服务类” 中，这个类就会变得臃肿不堪，职责也不再单一。此时，就需要把库存管理功能分离出来，放到 “库存管理类”，把促销活动管理功能放到 “促销活动类”。这样，每个类都只负责自己相关的职责，代码结构更清晰，维护和扩展也更方便。

再比如，在一个游戏开发项目中，有一个 “角色类”。在游戏初期，角色可能只有移动和攻击的基本功能，那么这两个功能放在 “角色类” 中是合理的。但当游戏要增加角色技能升级、装备穿戴等功能时，如果都堆在 “角色类” 里，就不符合单一职责原则了。我们可以把技能升级相关的逻辑放到 “技能管理类”，装备穿戴相关的逻辑放到 “装备管理类”，让 “角色类” 只专注于角色的基本行为，如移动和攻击。

所以说，单一职责原则中的职责划分不是一成不变的，它需要我们根据业务的发展和变化，灵活地进行调整和优化。在实际编程中，要多思考每个类的职责是否清晰、单一，避免出现职责混乱、耦合度过高的情况。