七大设计原则（一句话总结）

最新推荐文章于 2024-02-19 11:39:31 发布

原创最新推荐文章于 2024-02-19 11:39:31 发布 · 765 阅读

7 ·

CC 4.0 BY-SA版权

文章标签：

#开闭原则 #单一职责原则 #里氏替换原则 #依赖倒置原则 #接口隔离原则 #迪米特法则 #合成复用原则

C++ 专栏收录该内容

14 篇文章

订阅专栏

文章目录

一、单一职责原则
二、开闭原则
三、里氏替换原则：
四、依赖倒置原则
五、接口隔离原则
六、迪米特法则
七、合成复用原则

一、单一职责原则

类、函数、接口的职责单一

二、开闭原则

修改关闭，扩展开放

三、里氏替换原则：

基类和子类之间的关系，基类可以被子类替代

四、依赖倒置原则

依赖抽象接口，而不是具体对象

五、接口隔离原则

不对外暴露无用接口，接口按照功能细分

六、迪米特法则

一个对象尽量与其他对象少的交互，类间解耦，弱耦合，使得功能模块相对独立

七、合成复用原则

尽量使用组合和聚合（关联关系）代替继承来实现
因为：
1.继承复用破坏了类的封装性，父类的方法会暴露给子类
2.父类和子类耦合度高，父类的实现变化会影响子类，不利于类的扩展和维护

确定要放弃本次机会？

福利倒计时

: :

立减 ¥

普通VIP年卡可用

立即使用

中盾

关注关注

11
点赞
踩
7

收藏

觉得还不错? 一键收藏
0
评论
分享

复制链接

分享到 QQ

分享到新浪微博

扫一扫
举报

举报

专栏目录

一句话总结软件设计七大原则

NewBeeMu的博客

04-14

547

开闭原则、里氏替换原则、依赖倒置原则、单一职责原则、接口隔离原则、迪米特法则和合成复用原则这7 种设计原则是软件设计模式必须尽量遵循的原则，是设计模式的基础。在实际开发过程中，并不是一定要求所有代码都遵循设计原则，而是要综合考虑人力、时间、成本、质量，不刻意追求完美，要在适当的场景遵循设计原则。这体现的是一种平衡取舍，可以帮助我们设计出更加优雅的代码结构。各种原则要求的侧重点不同，下面我们分别用一句话归纳总结软件设计模式的七大原则，如下表所示。 设计原则 一句话归纳目的 开闭原则 对扩

【设计模式系列24】GoF23种设计模式总结及软件设计7大原则

zwx900102的博客

11-04

2861

设计模式总结及软件设计七大原则前言软件设计7大原则开闭原则（Open-Closed Principle，OCP）里氏替换原则（Liskov Substitution Principle，LSP）依赖倒置原则(Dependence Inversion Principle，DIP)单一职责原则(Single Responsibility Principle，SRP)接口隔离原则(Interface Segregation Principle，ISP)迪米特法则(Law of Demeter，LoD)合成复用原则

参与评论您还未登录，请先登录后发表或查看评论

七大设计原理

dsjyh的博客

10-03

857

设计原则

七个设计原理

Stay hungry, Stay foolish

02-22

2047

是什么七个设计原理是我们在设计代码结构时应考虑的核心观点，目的是避免代码中存在故障隐患。这些设计原理源于对实际软件开发现场的分析，是提高代码质量的经验结晶。人们从“怎样做才能在开发时避免代码中存在的故障隐患”的角度出发，分析一个个故障案例的根本原因，从而总结出了这些原理。七个设计原理是代码审查的标准判断。这七个设计原理如下：简单性原理同构性原理对称原理层次原理线性原理清晰原理安全原理为什么代码审查是保证软件质量的有效方法。不过，审查如果没有一定的价值观或观点

设计模式03——面向对象设计原则

如不來的博客

01-02

515

在软件开发中，为了提高软件系统的可维护性和可复用性，增加软件的可扩展性和灵活性，程序员要尽量根据 7 条原则来开发程序，从而提高软件开发效率、节约软件开发成本和维护成本。一、开闭原则 1、定义 开闭原则（Open Closed Principle，OCP）由勃兰特·梅耶（Bertrand Meyer）提出，他在 1988 年的著作《面向对象软件构造》（Object Oriented So...

设计模式-七大原则：原理背后的原理

热门推荐

前路无畏的博客

10-27

1万+

23中设计模式，是前任的经验总结，但是在这个原理的背后，还有原理在支撑，他们就是下面要介绍的7大原则，明白了这些原则，非常有用 a.面试时经常被问到。b.有助于对设计模式的学习。c.有助于自己的设计思想的养成与训练。 单一职责原则 一个类或者一个接口仅做一件事、或者一类事。 接口隔离原则 我业务类不应该依赖不需要的接口，即一个类对另一个类的依赖应该建立在最小的接口上，也就是倒逼我们的接口一定一定要建的颗粒度够小，如果我用到了多个接口的功能，那就实现多个就可以，别懒省事，把方法都写在一个接口中。

七大设计原则

琼歌

11-17

1万+

七大原则是程序员架构之路上躲不开的一道槛，只有掌握了七大原则和二十四设计模式才有能对代码进行高水平的重构，对源码的解读也会更加的轻松! 用抽象构建框架，用实现扩展细节是所有代码设计模式的基础。设计原则的出现是为了提高系统的可维护性和可复用性，提高系统的高内聚和低耦合! 每种设计原则的组合和使用都是在业务场景和需求量中进行取舍! =================================...

Java设计模式——七大设计原则

scorpio的博客

07-18

1752

单一职责原则、依赖倒置原则、接口隔离原则、开放关闭原则、里式替换原则、迪米特法则、组合复用原则

面向对象七大设计原则

二哈喇子！

07-06

1718

面向对象的几大原则你都知道吗

【设计模式】软件设计七大原则

技术分享，读书笔记，面试宝典，算法积累，应有尽有～

03-04

1849

设计原则不是强行遵守的，而是要讲究一个度，讲究一个取舍，最重要的是要结合合适的业务场景。

【七大软件架构设计原则详解】

qq_31532979的博客

02-19

1840

设计原则一句话归纳目的开闭原则对扩展开放，对修改关闭降低维护带来的新风险依赖倒置原则高层不应该依赖底层更利于代码结构的升级扩展单一职责原则一个类只干一件事便于理解，提高代码的可读性接口隔离原则一个接口只干一件事功能解耦，高聚合、低耦合迪米特法则不该知道的，不要知道只和朋友交流，不喝默认人说话，减少代码臃肿里式替换法则子类重写方法功能发生变化，不应该影响父类方法的含义防止继承泛滥合成复用原则尽量使用组合实现代码复用，而不是用继承降低代码耦合。

设计模式学习之七大原则

weixin_42797377的博客

03-08

751

设计模式学习之七大原则一、设计模式前言 1、设计模式的概念软件设计模式（Software Design Pattern），又称设计模式，是一套被反复使用、多数人知晓的、代码设计经验的总结。它描述了在软件设计过程中的一些不断重复发生的问题，以及该问题的解决方案。也就是说，它是解决特定问题的一系列套路，是前辈们的代码设计经验的总结，具有一定的普遍性，可以反复使用。其目的是为了提高代码的可重用性、代码的可读性和代码的可靠性。 2、设计模式的本质设计模式的本质是面向对象设计原则的实际运用，是对类的封装性、继承

源码分析七大设计原则之迪米特法则

用善良的眼光看世界

12-20

226

源码分析之七大设计原则 一、迪米特法则 定义：迪米特法则又叫最少知道原则，通俗的来讲：就是一个类对自己依赖的类知道的越少越好对于被依赖的类来说，无论逻辑多么复杂，都尽量地的将逻辑封装在类的内部，对外除了提供的 public 方法，不对外泄漏任何信息 迪米特法则还有一个更简单的定义：只与直接的朋友通信首先来解释一下什么是直接的朋友：每个对象都会与其他对象有耦合关系，只要两个对象之间有耦合关系，我们就说这两个对象之间是朋友关系耦合的方式很多，依赖、关联、组合、聚合等等，其中，我们称出现成员变量、方法参数、

设计模式七大原则的原理及其实现

weixin_43159275的博客

08-09

895

程序员编程应该遵守的原则，也是设计模式的设计依据（设计模式为什么这样设计的依据，因为遵守了这七大原则） 单一职责原则 概述：以一个类来说，一个类只负责一项职责，要是一个类负责两个不同的职责：职责1，职责2，当职责1因为后期需求变更需要改变这个类时，可能会造成职责2执行错误，所以可以将这个类分为类1和类2，分别承担这两项职责。 package com.itguigu.principle.sing...

设计模式：工厂方法模式（讲故事图文易懂）

Go_forward_的博客

12-31

1446

设计模式：工厂方法模式（通过讲故事图文易懂）

C++ prime Plus 第四章编程练习答案

Go_forward_的博客

01-31

1061

第三章编程练习目录总结一、第一题二、第二题三、第三题四、第四题五、第五题六、第六题七、第七题八、第八题九、第九题十、第十题总结函数由函数头和函数体组成。函数头指出函数的返回值（如果有的话即不为void）的类型和参数类型。函数先声明（或先定义），后使用。 const 声明常量。一、第一题题目：编写一个C++程序，如下述输出示例所示的那样请求并显示信息： What is your first name? Beety Sue What is your last name? Yewe What let

C++继承：public继承、protected继承、private继承

Go_forward_的博客

01-19

1055

C++继承：public继承、protected继承、private继承子类在类外只能访问公有继承来的父类的公有成员变量和公有成员函数子类在类内能够访问继承过来后属性为公有或保护的父类的成员变量和成员函数提示：可以利用下方文件目录跳转到三种继承的具体实现代码文章目录C++继承：public继承、protected继承、private继承结论一、公有继承1.子类在类内访问父类的成员变量和成员函数2.子类在类外访问父类的成员变量和成员函数二、保护继承1.子类在类内访问父类的成员变量和成员

设计模式：抽象工厂模式（讲故事易懂）

Go_forward_的博客

12-31

964

设计模式：抽象工厂模式（讲故事易懂）

C++ Primer Plus 第一章笔记

Go_forward_的博客

11-28

954

面向对象编程OOP理念是设计与问题本质对应的数据格式。 OOP不像过程性编程那样，试图使问题满足语言的过程性方法，而是试图让语言来满足问题的要求。 C++98，它不仅描述了已有的C++特性，还对该语言进行了扩展，添加了异常、运行阶段类型识别（RTTI）、模板和标准模板库（STL）。

如何判断一个Python类是否违反了单一职责原则？

最新发布

04-28

<think>好的，我现在要解决用户的问题：如何在Python中检查类是否遵循单一职责原则（SRP）并提供判断方法。用户之前已经问过关于Python类设计如何避免将太多函数塞进同一个类的问题，现在他想知道具体如何判断一个类是否违反了SRP。首先，我需要回忆一下单一职责原则的定义。SRP指出一个类应该只有一个引起变化的原因，也就是说，一个类应该只负责一个功能或职责。如果类承担了多个职责，那么修改其中一个职责可能会影响到其他不相关的功能，导致代码维护困难。接下来，我需要结合用户提供的引用内容。引用[1]、[2]、[3]、[4]都提到了SRP的应用和实例，特别是引用[2]详细解释了SRP的作用，引用[4]给出了一个分割模块的示例。用户之前的回答中也提到了拆分类的具体方法，比如组合模式、Mixin等。用户现在需要的是判断方法，也就是如何检查一个类是否违反SRP。根据之前的回答，可能包括方法数量、职责描述、修改原因等标准。需要把这些标准具体化，形成可操作的步骤。首先，我应该从代码结构入手。比如，类的方法是否属于同一类功能。例如，一个数据处理类如果同时包含数据清洗和数据库连接的方法，可能就违反了SRP。另外，类的方法命名是否具有一致性，比如以不同前缀开头可能暗示不同职责。然后，考虑职责描述测试。用户提到需要能用一句话描述类的职责，如果描述中出现“和”、“或者”等连接词，说明可能存在多个职责。例如，“处理数据并连接数据库”就明显有两个职责。另外，变更原因分析也是一个关键点。如果不同的功能需求变更导致同一个类需要修改，那么这个类可能承担了多个职责。比如，数据格式变化和数据库连接参数变化都需要修改同一个类，说明需要拆分。还有依赖关系检查。如果类导入了多个不相关的模块，比如同时导入数据处理和图形绘制的库，这可能意味着职责过多。例如，DataProcessor类导入了pandas和matplotlib，可能就是问题。测试复杂度也是一个指标。如果测试类时需要模拟多个外部依赖或者覆盖多个不同场景，可能说明职责过多。比如，测试一个类需要同时测试数据解析和网络请求，这可能违反SRP。代码示例部分，需要给出正例和反例，帮助用户理解。比如，引用[3]中的Animal类只负责呼吸，而如果Animal类还负责移动，就需要拆分。最后，提供工具辅助检查，比如Pylint、Radon等，这些工具可以计算代码复杂度，帮助识别问题。但需要说明工具只是辅助，主要还是依靠设计原则判断。总结下来，判断方法应包括结构分析、职责描述、变更原因、依赖检查、测试复杂度以及工具使用。需要将这些步骤组织成清晰的条目，并提供具体示例，让用户能够逐步应用这些方法检查自己的代码。</think>### Python类SRP符合性检测方法 #### 一、代码结构分析法 1. **方法聚类检测** - 统计类中方法的**动词前缀一致性**：例如$UserManager$类中出现`process_payment()`和`render_template()`，动词`process`与`render`暗示不同职责[^2] - 示例检测代码： ```python class SRPChecker: @staticmethod def check_method_prefixes(cls): prefixes = [m.split('_')[0] for m in dir(cls) if not m.startswith('_')] return len(set(prefixes)) > 3 # 超过3种动词前缀触发警告 ``` 2. **方法关联度计算** 使用代码耦合度指标： ```python # 安装分析工具：pip install radon from radon.complexity import cc_visit def calculate_coupling(code): results = cc_visit(code) return sum(item.complexity for item in results) ``` 当类内方法平均耦合度>7时需警惕[^4] #### 二、语义化判断标准 1. **职责描述测试** - 要求用**一句话**完整描述类的功能 - 通过示例说明： ```python # 反例：DataHandler 类的描述 "处理CSV文件解析、数据库连接和生成PDF报告" # 包含3个职责 # 正例：PDFGenerator 类的描述 "将结构化数据转换为PDF格式文档" # 单一职责 ``` 2. **变更原因验证** 创建变更记录表进行验证： | 修改时间 | 修改内容 | 触发原因 | 影响范围 | |------------|-------------------|----------------------|-----------------| | 2024-03-01 | 调整数据加密算法 | 安全策略升级 | encrypt_data() | | 2024-03-05 | 修改API响应格式 | 前端界面改版需求 | format_response() | 若同一类出现**不同业务原因**的修改，说明违反SRP[^1] #### 三、依赖关系检测 1. **导入模块分析** 检查类的导入语句： ```python # 反例：混合导入数据处理和界面库 import pandas as pd from matplotlib import pyplot as plt # 正例：专注数据库操作 import psycopg2 from sqlalchemy import create_engine ``` 2. **参数类型多样性** 统计方法参数类型： ```python def analyze_parameters(cls): param_types = [] for method in cls.__dict__.values(): if callable(method): annotations = method.__annotations__ param_types.extend(annotations.values()) return len(set(param_types)) > 5 # 超过5种类型触发警告 ``` #### 四、测试用例验证法 1. **测试覆盖率差异检测** 当出现以下情况时需注意： ```text test_data_processing.py 覆盖率 95% test_report_generation.py 覆盖率 30% # 同一类不同功能测试覆盖率差异过大 ``` 2. **Mock对象复杂度** 记录单元测试中需要的模拟对象数量： ```python # 反例测试样例 def test_process_data(self): mock_db = Mock(DatabaseConnector) # 模拟数据库 mock_parser = Mock(DataParser) # 模拟数据解析器 processor = DataProcessor(mock_db, mock_parser) # 需要多个模拟对象 ... ``` #### 五、工具辅助检测 1. **Pylint规则扩展** 自定义.pylintrc配置： ```ini [DESIGN] max-methods=10 # 类方法数量阈值 max-locals=15 # 单个方法代码行数 max-returns=6 # 方法返回路径数量 ``` 2. **可视化分析（使用pyreverse）** ```bash pyreverse -o png -p Project *.py ``` 生成的类关系图中，若发现类有**多个入方向箭头**或**多组关联模块**，则可能违反SRP[^3] #### 六、典型模式对照表 | 违规特征 | 合规特征 | 检测方法 | |---------------------------|---------------------------|------------------------| | 方法使用不同领域的术语 | 方法动词前缀一致 | 语义分析 | | 需要同时Mock多个外部服务 | 仅需1-2个测试替身 | 单元测试审查 | | 类描述包含"和/与"等连词 | 能用名词短语精确描述 | 文档审查 | | 频繁因不同原因被修改 | 修改原因保持单一 | 版本历史分析 | #### 七、代码示例验证 ```python # 违反SRP的类 class FileManager: def read_csv(self, path): ... # 数据读取职责 def encrypt_data(self, data): ... # 数据加密职责 def send_email(self, content): ... # 通知发送职责 # 符合SRP的拆分方案 class CSVReader: ... # 只负责文件读取 class DataEncryptor: ... # 只负责加密 class EmailNotifier: ... # 只负责通知 ``` 通过上述方法可系统化检测SRP合规性，当发现类同时具备$数据处理+通信+安全$等跨领域功能时，应立即启动重构[^4]