设计模式的七大原则

最新推荐文章于 2025-12-24 14:43:50 发布
原创 最新推荐文章于 2025-12-24 14:43:50 发布 · 693 阅读 · 14 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#设计模式

设计模式概述

  • 就是某类问题的通用解决方案，代表了最佳实践
  • 设计模式的本质是提高软件的维护性、通用性和扩展性，并降低软件的复杂度
  • 设计模式分为了三类，共23种：
    • 创建型模式：单例模式、抽象工厂模式、原型模式、建造者模式、工厂模式
    • 结构性模式：适配器模式、桥接模式、装饰模式、组合模式、外观模式、享元模式、代理模式
    • 行为型模式：模板方法模式、命令模式、访问者模式、迭代器模式、观察者模式、中介者模式、备忘录模式、解释器模式、状态模式、策略模式、职责链模式

使用设计模式的目的

  • 代码重用性：相同的代码，不用重复编写
  • 可读性：编码的规范性
  • 可扩展性：增加新功能时，非常方便
  • 可靠性：增加新的功能，对原有的功能没有影响
  • 高内聚、低耦合：模块内部很紧密，模块和模块间很松散

设计原则的核心思想

  • 找出应用中可能需要变化之处，把他们独立出来
  • 对针对接口编程。而不是针对实现编程
  • 为了交互对象之间的松散耦合设计而努力

设计模式的七大原则

  • 单一职责原则
  • 接口隔离原则
  • 依赖倒转原则
  • 里氏替换原则
  • 开闭原则（ocp）
  • 迪米特法则
  • 合成复用原则

单一职责原则

  • 对类来说，一个类应该只负责一项职责
  • 如果一个类负责两个职责：职责1和职责2，当职责1变化时有可能会引起职责2的变化，所以应该把这个类的粒度分为A1和A2
  • 优点：
    • 可以降低类的复杂度
    • 提高了类的可读性，可维护性
    • 降低了变更引起的风险
  • 通常情况下应该遵循单一职责原则，除非逻辑足够简单，才能在代码层面违反单一职责原则
  • 只有类中的方法足够少，可以在方法级别保持单一职责原则，如果方法很多，还是应该分成多个类

接口隔离原则

  • 客户端不应该依赖他不需要的接口，即一个类对另一个类的依赖应该建立在最小的接口上
  • 例如：
    • 接口类interface1有三个接口，实现类A只会用到其中两个接口，也必须实现剩下一个接口，出现这种情况，就说明interface1不是最小接口，存在不需要的接口，违反了接口隔离原则
    • 所以需要把interface1拆分为独立的接口，实现类只和他们需要的方法建立依赖关系

依赖倒转原则

  • 高层模块不应该依赖低层模块，二者都应该依赖其抽象
  • 抽象不应该依赖细节，细节应该依赖抽象
  • 依赖倒转的中心思想是面向接口编程
  • 相对于细节的多变性，抽象的东西要稳定的多，以抽象为基础搭建的架构比细节为基础的架构要稳定的多，在java中，抽象指的是接口或则抽象类，细节就是具体的实现类
  • 使用接口或者抽象类的目的是制定好规范，而不涉及任何具体的操作，把展示细节的任务交给他们的实现类去完成

里氏替换原则

  • 继承
    • 继承包含了这么一层含义：父类中凡是已经实现好的方法，实际上就是在设定规范，虽然不要求所有子类必须遵循这写规范，但是如果子类对这些已经实现的方法做任意修改，就会对整个继承体系造成破坏
    • 继承再给程序设计带来便利的同时，也带来了弊端，例如：
      • 使用继承会给程序带来侵入性，是程序的可移植性降低，增加了对象间的耦合关系
      • 如果一个类被其他类继承，对这个类的修改必须考虑其他子类，并且修改父类后，所有子类的功能都有可能出现问题
  • 里氏替换原则描述了如何正确的使用继承
    • 如果对每个类型为T1的对象o1，都有类型为T2的对象o2，使得以T1定义的所有程序P在所有的对象o1都替换成o2时，程序的行为没有发生变化，那么类型T2是类型T1的子类型
    • 也就是说：所有引用基类的地方必须能透明使用其子类的对象
    • 所以在使用继承时，遵循里氏替换原则，在子类中尽量不要重写父类中的方法
    • 继承会增加两个类的耦合，在适当的情况下，可以通过聚合、组合、依赖来解决问题，例如抽取更基础的父类

开闭原则（ocp）

  • 开闭原则（open closed principle）是编程中最基础也是最重要的设计原则
  • 一个软件实体，例如类，应该对扩展开放（接口提供方），对修改关闭（对接口调用方）
  • 当软件需要变化时，尽量通过扩展软件实体，而不是修改已有的代码来实现，当我们想给类增加新的功能的时候，尽量不修改代码，或者少修改代码
  • 设计模式的目的就是遵循开闭原则，开闭原则是核心

迪米特法则

  • 一个对象应该对其他对象保持最小的了解
  • 类与类关系越密切，耦合度越大
  • 迪米特法则的核心是降低类之间的耦合
  • 迪米特法则又叫最少知道原则，即一个类对自己依赖的类知道的越少越好，对于被依赖的类不管多么复杂，都尽量将逻辑封装在类的内部
  • 迪米特法则还有个更简单的定义，只与直接的朋友通信，应该避免类中出现非直接朋友的耦合（对于被依赖的类不管多么复杂，都尽量将逻辑封装在类的内部），直接的朋友指的是：
    • 每个对象都会与其他对象有耦合关系，只要两个对象之间有耦合关系，就认为这两个类是朋友关系
    • 耦合的方式有很多，例如：依赖、关联、组合、聚合等
    • 出现成员变量、方法参数、方法返回值的类为直接朋友，出现在局部变量中的类不是直接朋友，陌生的类最好不要以局部变量的形式出现在类的内部

合成复用原则

  • 尽量使用合成、聚合的方式，而不是使用继承
设计模式七大原则详解
欢迎每一位朋友不吝赐教，无论是宝贵的建议还是中肯的批评，都将是我前进路上不可或缺的灯塔
09-09 1605
设计模式的七大原则，主要包括单一职责原则，开闭原则，里氏替换原则，依赖倒转原则，接口隔离原则，迪米特原则，合成/聚合复用原则。详细介绍每种原则和使用Java代码实现
设计模式七大原则
qq_51626500的博客
01-03 1702
设计模式七大原则
详细介绍设计模式七大原则
m0_54187478的博客
02-19 3282
单一职责原则：一个类应该只有一个引起它变化的原因。开闭原则：软件实体应对扩展开放，对修改封闭。里氏替换原则：子类型必须能够替换掉它们的基类型。依赖倒置原则：高层模块不应依赖于低层模块，两者都应依赖于抽象；抽象不应依赖于细节，细节应依赖于抽象。接口隔离原则：使用多个专门的接口比使用单一的总接口更好。合成/聚合复用原则：尽量使用对象的组合/聚合，而不是继承关系达到复用的目的。迪米特法则（最少知道原则）：一个对象应对其他对象有尽可能少的了解。
设计模式——设计模式七大原则
weixin_73659282的博客
09-11 2066
本专栏主要记录软件设计模式的基本知识内容以及各种设计模式，通过案例和代码以及图解来更好的学习和了解软件设计模式的相关内容。
设计模式七大原则（案例解析）
Android系统优化
11-25 4657
一、 设计模式的目的 编写软件过程中，程序员面临着来自 耦合性，内聚性以及可维护性，可扩展性，重用性，灵活性 等多方面的挑战，设计模式是为了让程序(软件)，具有更好 1) 代码重用性 (即：相同功能的代码，不用多次编写) 2) 可读性 (即：编程规范性, 便于其他程序员的阅读和理解) 3) 可扩展性 (即：当需要增加新的功能时，非常的方便，称为可维护) 4) 可靠性 (即：当我们增加新的功能后，对原来的功能没有影响) 5) 使程序呈现高内聚，低耦合的特性 二. 设计模式七大原则 ...
尚硅谷学习笔记——Java设计模式（一）设计模式七大原则
five小点心的博客
11-28 1610
什么是设计模式？设计模式常用的七大原则是什么？
设计模式——七大设计原则
weixin_43412762的博客
12-05 4184
设计模式的七大原则：开闭原则、里氏代换原则、依赖倒转原则、接口隔离原则、合成复用原则、迪米特法则
Java设计模式之七大设计原则
热门推荐
qq_49529322的博客
04-28 1万+
Java设计模式之七大设计原则 本文对Java设计模式中的七大设计原则进行汇总介绍，提炼最核心的概念。 设计模式总结笔记 一、设计模式七大原则 设计模式的目的： 代码可重用性：相同功能的代码，不用多次编写。 可读性：编程规范性，便于其他程序员的阅读和理解。 可扩展性：当需要增加新的功能的时候，非常方便，称为可扩展性。 可靠性：当我们新增功能后，对原来的功能没有影响。 使程序呈现高内聚、低耦合特性。 1.1、单一职责原则 不遵守单一职责原则： 对类来说的，就是一个类应该只负责一项职责。 比如：Us
设计模式七大原则——开闭原则
贝尔摩德苦艾酒
02-06 1万+
设计模式七大原则——开闭原则
设计模式七大原则——迪米特原则
贝尔摩德苦艾酒
02-06 9372
设计模式七大原则——迪米特原则
Java设计模式七大原则-单一职责原则.md
08-13
设计模式
Java设计模式七大原则-合成聚合复用原则.md
08-13
java八股文
yoyiyi#SoleilNotes#001.设计模式七大原则1
07-25
2.1 单一职责原则 2.2 接口隔离原则 2.3 依赖倒置原则 2.4 里式替换原则 2.5 开闭原则 2.6 迪米特原则 2.7 合成复用原则
设计模式：命令模式
技术分析
12-23 541
命令模式是一种行为型设计模式，将请求封装为独立对象，实现发送者和执行者的解耦。其核心角色包括抽象命令、具体命令、调用者和接收者。典型应用场景如订单操作，通过命令对象绑定接收者和参数，调用者只需触发执行而无需了解具体实现。该模式支持扩展特性如命令撤销/重做、命令队列和宏命令组合。与策略模式不同，命令模式聚焦请求封装和解耦，而非算法切换。优点在于良好的解耦性和扩展性，但可能增加系统复杂度。适用于需要支持请求队列化、撤销或批量执行的场景，如Spring MVC框架中的请求处理机制。
Vue设计模式深度解析：渐进式框架背后的优雅哲学
码农捻旧的博客
12-19 600
Vue.js作为渐进式框架，其设计哲学融合了响应式编程与编译优化两大核心技术。框架采用Proxy实现细粒度依赖追踪，相比React的虚拟DOM Diff具备精确更新优势，无需手动优化即可实现高性能渲染。Vue的模板编译器通过静态提升、Patch Flags等优化技术显著提升性能，而Vapor Mode更彻底地绕过虚拟DOM，直接操作DOM实现极致性能。这种"中庸之道"的设计使Vue既保持了开发友好性，又能适应从简单页面到复杂应用的各种场景。
Head First设计模式（十二） 设计原则 复合模式
zyl042的博客
12-19 162
模式通常被一起使用，并结合在同一个设计解决方案中。复合模式在一个解决方案中结合两个或多个模式，以解决一般的或重复发生的问题。 呈现模型，视图通常直接从模型中取得显示所需的状态和数据。 取得用户输入并解读其对模型的含义。 模型持有所有数据，状态和应用逻辑。模型对视图和控制器是无视的，虽然它提供了操纵和检索其状态的接口，并发送状态改变通知给观察者。
设计模式之-工厂模式
syt_1013的博客
12-19 328
假设有产品 A，B，C，那么在标准的工厂方法模式里面，就有对应的工厂 A，B，C，假设现在需要新增一个产品 D，我们只需要新增一个对应的工厂 D 即可，原来的工厂是不受任何影响的。在抽象工厂模式中，会有一个产品族的概念，一个产品族（一个系列）会对应一组产品，之后一个工厂在生产的时候，是生产这一组产品，而非单个的某个产品。每增加一个产品，就需要增加一个工厂，当我们的产品的数量很多的时候，就会使得工厂的数量也成倍的增加。3.2产品：通过调用工厂给客户端提供的接口，所得到的对象。5.先写一个简单的工厂模式吧。
Python设计模式：抽象工厂模式详解
数据知道的博客
12-19 242
本文介绍了抽象工厂模式的设计思想与应用场景。抽象工厂模式提供一个接口用于创建一系列相关或相互依赖的对象（产品族），而不需指定具体类。其核心思想是处理产品族的创建，如不同风格的UI组件或跨平台数据库连接。文章通过UML图展示了抽象工厂、具体工厂、抽象产品和具体产品四个核心角色，并分析了该模式的优缺点：优点包括确保产品兼容性、解耦客户端与具体产品；缺点则是扩展性差和类数量爆炸。典型应用场景包括跨平台UI工具包和数据库访问层。最后通过Python代码示例展示了如何实现跨平台数据库连接，并比较了抽象工厂模式与工厂方
智能体（Agent）架构设计模式：基于实际项目的模块拆解
最新发布
书山有路勤为径，学海无涯苦作舟。
12-24 729
本文探讨了智能体（Agent）架构的设计模式，基于金融分析等实际项目经验，深入拆解了智能体的核心模块和工程化路径。文章指出，智能体正从简单的"输入-输出"模式转变为具有"目标-规划-执行-反思"完整循环的自治系统，并面临可靠性、可控性等六大挑战。通过金融分析案例，详细解析了感知与理解、规划与决策等五大核心模块的设计要点，包括分层意图识别、弹性计划生成等关键技术，为构建生产级智能体系统提供了实用框架。
设计模式 七大原则详解
12-31
### 设计模式七大原则详解 #### 单一职责原则 (SRP) 单一职责原则指出一个类应该只有一个引起它变化的原因。如果一个类承担了过多的责任，则会增加其复杂度，降低系统的稳定性。因此，在设计时应确保每个类只负责一项功能[^1]。 ```java // 正确做法：分离不同职责到不同的类中 class User { private String name; public void setName(String newName){ this.name = newName; } } ``` #### 开闭原则 (OCP) 开闭原则强调软件实体应对扩展开放而对修改关闭。这意味着可以通过添加新代码的方式使系统行为发生改变而不必改动现有源码。利用接口或抽象基类可以很好地支持这一特性[^3]。 ```csharp public interface IShape{ double GetArea(); } public class Circle : IShape{/*...*/} public class Rectangle : IShape{/*...*/} // 新增形状无需更改原有逻辑 List<IShape> shapes = new List<IShape>(); shapes.Add(new Circle()); shapes.Add(new Rectangle()); foreach(var shape in shapes){ Console.WriteLine(shape.GetArea()); } ``` #### 里氏替换原则 (LSP) 该原则规定子类型必须能够完全替代它们的父类型。任何原本使用基类对象的地方都可以直接替换成派生类的对象而不影响程序正确性。这有助于提高继承结构的安全性和灵活性[^2]。 ```cpp class Bird { virtual void fly()=0; }; class Sparrow : public Bird {/* 实现fly方法 */}; class Ostrich : public Bird {/* 不实现fly,违背此原则 */} ``` #### 接口隔离原则 (ISP) 接口隔离原则提倡客户端不应该依赖于那些他们不使用的接口；多个特定客户专用的小接口优于一个通用的大接口。这样做可以让各个组件之间的耦合更加松散，便于后期维护和升级。 ```typescript interface IPrinterOperations { print():void; } interface IFaxOperations { sendFax(faxData:string):boolean; } class ModernPrinter implements IPrinterOperations,IFaxOperations {/* ... */} ``` #### 依赖倒置原则 (DIP) 高层模块不应依赖低层模块，二者都应该依赖于抽象；具体而言就是面向接口编程而非具体的实现。这样的架构使得整个应用程序更易于测试、重构以及适应未来需求的变化。 ```python from abc import ABCMeta, abstractmethod class Switchable(metaclass=ABCMeta): @abstractmethod def turn_on(self)->None: pass def switch_power(device:Switchable): device.turn_on() ``` #### 迪米特法则/最少知道原则 (LoD) 迪米特法则是指一个对象应当对其它对象有尽可能少的了解。换句话说，尽量减少相互间的交互关系，保持较低程度的耦合状态。这样做的好处是可以简化调试过程并增强系统的健壮性。 ```php <?php class LightBulb { function on(){/*...*/} function off(){/*...*/} } $lightbulb=new LightBulb(); // 避免过度暴露内部属性给外部调用者 echo $lightbulb->on(); ?> ``` #### 合成聚合复用原则 (CARP) 合成聚合复用原则建议优先考虑组合/聚合方式重用已有组件的功能，而不是通过继承机制来达到目的。因为前者通常具有更好的可读性和更高的内聚力，同时也更容易理解和管理。 ```xml <!-- XML配置文件 --> <person> <name>John Doe</name> <!-- 使用地址作为组成部分 --> <address street="Main St." city="Springfield"/> </person> ```
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值