Single Responsibility Principle (SRP) – 职责单一原则 --- （原则之五）

最新推荐文章于 2024-08-20 08:53:47 发布
原创 最新推荐文章于 2024-08-20 08:53:47 发布 · 838 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

单一职责原则，其核心的思想是：一个类，只做一件事，并把这件事做好，其只有一个引起它变化的原因。单一职责原则可以看作是低耦合、高内聚在面向对象原则上的引申，将职责定义为引起变化的原因，以提高内聚性来减少引起变化的原因。职责过多，可能引起它变化的原因就越多，这将导致职责依赖，相互之间就产生影响，从而极大的损伤其内聚性和耦合度。单一职责，通常意味着单一的功能，因此不要为一个模块实现过多的功能点，以保证实体只有一个引起它变化的原因。强调专一性;
SOLID原则学习，单一职责原则（Single Responsibility Principle, SRP）
汽车电子软件领域知识分享
01-08 737
单一职责原则通过将类的职责分离，使得每个类都专注于一个功能领域，从而提高了代码的可维护性、可复用性和可测试性。在实际开发中，遵循SRP可以帮助我们设计出更加清晰、灵活的软件系统。
深入理解设计原则之单一职责原则(SRP)【软件架构设计】
weixin_30197685的博客
05-28 2573
单一职责原则(Single Responsibility Principle, SRP)的描述：一个类或模块只负责完成一个职责(或功能)。注意单一职责原则描述的对象有两个：类(Class)和模块(Module)。关于这两个概念我们有两种理解方式。一种理解方式把模块看作比类更抽象的概念，把类看作一种模块。另一种理解方式把模块看作更粗粒度的代码块，多个类组成一个模块。无论哪种理解方式，单一职责原则在应用这两个描述对象时，原理是相通的。粒度小，功能单一。
单一职责原则（Single Responsibility Principle）
aijianxie8808的博客
06-16 205
单一职责原则（SRP：The Single Responsibility Principle） 一个类应该有且只有一个变化的原因。 There should never be more than one reason for a class to change. 为什么将不同的职责分离到单独的类中是如此的重要呢？ 因为每一个职责都是一个变化的中心。当需求变化时，这个变...
深入理解JavaScript系列（6）：S.O.L.I.D五大原则之单一职责SRP
weixin_33854644的博客
01-06 234
前言 Bob大叔提出并发扬了S.O.L.I.D五大原则，用来更好地进行面向对象编程，五大原则分别是： The Single Responsibility Principle（单一职责SRP） The Open/Closed Principle（开闭原则OCP） The Liskov Substitution Principle（里氏替换原则LSP） The Interface Seg...
六大设计原则——单一职责原则【Single Responsibility Principle】
mjd的专栏
08-04 2683
声明：本文内容是从网络书籍整理而来，并非原创。用户管理的例子 先看一张用户管理的类图： 再看一眼上面的图，思考：这样合理吗？ 这个接口是一个很糟糕的设计！ 用户的属性和行为竟然混合在一起！！！ 正确的做法是把用户的信息抽取成一个业务对象(Bussiness Object,简称 BO)，把行为抽取成另外一个接口中，我们把这个类图重新画一下： 这样划分成了两个接口，IUserBO 负责用户的属性，I
单一职责原则(single responsibility principle,SRP)
jerry_zhang402的专栏
11-28 522
单一职责原则(single responsibility principle,SRP):        是指“就一个类而言，应该只有一个引起它变化的原因”。符合“高内聚低耦合”的标准。     分析：     1）防止相同类型的职责，分离到不同的类中，即我们需要提高代码的可重用性。     2）同一个类无需编织多余的职责，即做事专一，符合中华民族的“从一而终”的传统美德。     优势：
六大设计原则之单一设计原则
weixin_30897079的博客
02-27 182
Single Responsibility Principle（SRP）：单一设计原则 它规定一个类只有一个发生变化的原因。如果多余一个导致类变更的原因，则违反了SRP。 问题来源： 分别建立两个类T1、T2，使T1完成职责P1功能，T2完成职责P2功能。这样当修改T1时，不会使职责P2发生故障风险，同理当修改T2时，也不会使P1发生故障。 但是现实中，不管是新手，还是资深程序员...
软件设计七大原则详解 1. 单一职责原则（Single Responsibility Principle, SRP） 1.1 原则定义 1.2 为什么需要单一职责原则？ 1.3 违反单一职责原则的例子
04-24
1. 单一职责原则（Single Responsibility Principle, SRP） 1.1 原则定义 1.2 为什么需要单一职责原则？ 1.3 违反单一职责原则的例子 1.4 应用单一职责原则的改进 1.5 现实应用场景 1.6 单一职责原则的注意事项 2. ...
设计模式六大原则（一）——单一职责原则(SRP)
来北欧写代码
08-20 1280
单一职责原则的核心思想是：一个类应该仅有一个引起它变化的原因。换句话说，一个类应该负责一组相对独立且内聚的职责。当这个类需要承担更多的职责时，就应该考虑将其拆分为多个类，每个类负责一个单一的职责。单一职责原则是面向对象设计中的一个重要原则，它要求一个类只负责一个职责。遵循这一原则，可以使得我们的代码更加清晰、易于维护和扩展。在实际开发中，我们应该时刻关注类的职责划分，确保它们符合单一职责原则。
6单一职责原则-课程内容.rar
09-14
其中，“单一职责原则”（Single Responsibility Principle，SRP）是面向对象设计的五个核心原则之一，由罗伯特·C·马丁（Robert C. Martin）在其著作《Clean Code》中提出。这个原则强调一个类或模块应该只有一个...
The Single Responsibility Principle (SRP) - OO设计的单一职责原则
mty的专栏
12-11 484
The Single Responsibility Principle (SRP) - OO设计的单一职责原则（全文）：http://www.lifevv.com/sysdesign/doc/20071205215652027.html 
面向对象设计原则-----单一职责原则SRP(Single-Responsibility Principle)
weixin_30823833的博客
07-10 125
就一个类而言，应该仅有一个引起它的变化的原因。避免相同的职责分散到不同的类之中，避免一个类承担过多的职责。减少类之间的耦合，当需求变化时，只修改一个地方。 下面是一个档案类，有添加，修改，删除，获取档案信息，通过档案的档号得到档案分类。 在我的系统中通过档号得到档案分类的规则需要经常变化，当通过档号得到档案分类的规则变化时会影响整个类。这时将类重构为...
敏捷开发之原则 五大原则 SRP OCP LSP DIP ISP
热门推荐
心之所向
02-08 1万+
一、面向对象设计原则内容来自《敏捷开发：原则、模式与实例》 SRP单一职责原则（Single Responsibility Principle）： 就一个类而言，应该仅有一个引起它变化的原因。 OCP开放-封闭原则（Open Closure Principle）： 软件实体（类，模块，函数等）应该可以扩展的，但不可修改。 LSPLiskov 替换原则（Liskov Substitution
设计模式六大原则（1）单一职责原则（Single Responsibility Principle）
GodV的博客
08-04 2215
单一职责原则（Single Responsibility Principle）定义：不要存在多于一个导致类变更的原因。通俗的说，即一个类只负责一项职责。问题由来：类T负责两个不同的职责：职责P1，职责P2。当由于职责P1需求发生改变而需要修改类T时，有 可能会导致原本运行正常的职责P2功能发生故障。解决方案：遵循单一职责原则。分别建立两个类T1、T2，使T1完成职责P1功能，T2完成职责P2功能。
设计模式之单一职责原则的定义，个人理解，好处，以及使用
u013675978的博客
09-11 1443
单一职责原则的英文名称是Single Responsibility Principle，简称是SRP。 单一职责原则的定义是：应该有且仅有一个原因引起类的变更。 SRP的原话解释是： There should never be more than one reason for a class to change.   单一职责原则有什么好处： ● 类的复杂性降低，实现什么职责都有清晰明确...
面向对象设计原则
马摆摊
08-11 866
单一职责原则： 一个类最好只负责一件事，只有一个引起它变化的原因。 违背单一职责原则： 在一个方法中写分支判断，分别取执行不同的逻辑，功能虽然可以实现，但如果修改需求，就会变得很不稳定。 遵循单一职责原则： 拆分：父类 + 各个不同的实现类 举例： class Animal { public void breathe(string animal) { Debug.Log(animal + "呼吸空气"); } } public class test :
OO设计五大原则
戮筱沫博客
07-08 5631
OO的五大原则是指SRP、OCP、LSP、DIP、ISP 1. SRP（Single Responsibility Principle 单一职责原则）  单一职责很容易理解，所谓单一职责，就是一个设计元素只做一件事。 SRP 原则的核心含义是只能让一个类有且只有一个职责，永远不要让一个类存在多个改变的理由。换句话说，如果一个类需要改变，改变它的理由永远只有一个，如果存在多个改
系统设计原则--SRP OCP LSP DIP ISP
numenshane1的专栏
12-13 2264
一、单一职责原则（SRP）      每个类应当只负责单一内聚的职责，每一个职责都是变化的一个轴线，当需求变化时，该变化会反映为类的职责的变化。一个类应当仅有一个引起它变化的原因，如果一个类承担了多于一个的职责，那么引起它变化的原因就会有多个，等于把这些职责耦合在了一起。违反SRP的设计通常可以采用门面模式或代理模式进行重构，分离业务的职责。二、开闭原则（OCP）      软件实体（类、包、模块等）应该是可以扩展的，但是不可修改的，即对于扩展是开放的，对于修改是封闭的，对实体的行为扩展时，无需改动源代码或
《大话设计模式》单一职责原则、开放封闭原则、依赖倒转原则、里氏代换原则
乾坤未定，你我皆是黑马
01-29 150
单一职责原则 就一个类而言，应该仅有一个引起它变化的原因。 如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭受到意想不到的破坏。 开放封闭原则 软件实体（类、模块、函数等）应该可以扩展，但是不可修改。 对于扩展是开放的，对于更改是封闭的。 面对需求，对程序的改动是通过增加新代码进行的，而不是更改现有的代码。 ...
如何理解Single-responsibility principle (SRP)？
最新发布
12-14
<think>我们正在讨论单一职责原则（SRP）。根据引用内容，单一职责原则的核心是：一个类应该只有一个引起它变化的原因，或者说只专注于做一件事。这有助于降低类的复杂性，提高可读性和可维护性，并减少变更引起的风险。 引用[2]中有一个很好的例子：一个Modem接口有两个职责（连接管理和数据通信），这违反了SRP。我们可以将其拆分成两个接口：一个处理连接（dial和hangup），另一个处理数据通信（send和recv）。 引用[3]和[4]强调了SRP的好处：降低复杂性、提高可读性、提高可维护性、降低变更风险。 因此，我们可以这样理解SRP： 1. 一个类（或模块、方法）应该只有一个职责。 2. 职责是变化的原因，如果一个类有多个变化的原因，就需要拆分。 下面我们用代码示例来说明： 违反SRP的类： ```java // 这个类负责两个职责：用户信息管理和用户显示 class User { private String name; private String email; // 构造函数等 // 职责1：管理用户信息 public void saveUser() { // 将用户信息保存到数据库 } // 职责2：显示用户信息 public void displayUser() { System.out.println("Name: " + name); System.out.println("Email: " + email); } } ``` 按照SRP拆分后： ```java // 只负责用户信息的存储和获取 class User { private String name; private String email; // getters and setters } // 负责用户信息的持久化 class UserRepository { public void saveUser(User user) { // 保存到数据库 } } // 负责用户信息的显示 class UserDisplay { public void displayUser(User user) { System.out.println("Name: " + user.getName()); System.out.println("Email: " + user.getEmail()); } } ``` 这样，如果用户信息的存储方式变化，我们只需修改UserRepository；如果显示方式变化，只需修改UserDisplay。而User类只负责保存用户数据。 注意：职责的划分并不是绝对的，需要根据具体场景。引用[1]提到，职责的界限并不清晰，需要经验。 总结： 单一职责原则要求我们将不同的职责分离，使得每个类只承担一个职责，从而降低系统的耦合度，提高系统的可维护性。 现在，根据要求，生成相关问题： </think> ### 理解单一职责原则（SRP） 单一职责原则（Single-responsibility Principle，SRP）是面向对象设计的**核心原则**之一，其核心思想可概括为： > **一个类应该只有一个引起变化的原因**（或：一个类只负责一项职责） #### 核心要点解析 1. **职责的定义** 职责即"变化的原因"。如果一个类承担多个职责，当某个职责需求变更时，可能影响其他无关功能。 > "当发现有两个变化会要求修改这个类，就要考虑拆分它"[^2] 2. **设计目标** - 降低类的复杂度：每个类功能单一明确 - 提高可维护性：修改局部化，不影响其他模块 - 增强可读性：类功能一目了然 - 减少变更风险：避免"牵一发而动全身"[^3] #### 违反SRP的典型示例 ```java // 违反SRP：同时负责用户管理和日志记录 class UserManager { public void createUser(String username) { // 1. 创建用户逻辑 System.out.println("Creating user: " + username); // 2. 记录日志（混杂的职责） log("User created: " + username); } private void log(String message) { // 日志记录实现 System.out.println("[LOG] " + message); } } ``` **问题**：当需要修改日志格式或存储方式时，必须修改`UserManager`类，可能影响核心用户管理功能[^4]。 #### 遵循SRP的重构方案 ```java // 职责1：专用户管理 class UserManager { private Logger logger; // 通过依赖注入解耦 public UserManager(Logger logger) { this.logger = logger; } public void createUser(String username) { // 单一职责：用户创建 System.out.println("Creating user: " + username); logger.log("User created: " + username); } } // 职责2：专日志记录 class Logger { public void log(String message) { // 单一职责：日志处理 System.out.println("[LOG] " + message); } } ``` **优势**： - 用户管理变更不会影响日志系统 - 日志策略可独立扩展（如改为文件存储） - 代码可读性和可测试性显著提升 #### SRP的实践指导 1. **职责判断标准** - 检查类的方法是否服务于同一目标 - 分析需求变更时哪些方法会一起修改 - 方法间是否存在"与/或"关系（如保存数据并发送通知） 2. **粒度把握** 避免过度拆分导致"类爆炸"，合理场景包括： - 数据持久化与业务逻辑分离 - 界面渲染与数据处理分离 - 核心算法与异常处理分离 3. **设计收益** $$ \text{可维护性} \uparrow \quad \text{耦合度} \downarrow \quad \text{复用性} \uparrow $$ 系统复杂度随规模增加呈线性而非指数增长[^1] > "就像社会分工：专人做专事，系统才高效"[^2]
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值