设计模式七大原则小记(单一原则、接口隔离原则、依赖倒转原则、里氏替换原则、开闭原则、迪米特法则、合成复用原则)

AI权益加码!Claude Code、Cursor等20+工具免费用! 购周边限时加赠Coding Plan Lite,畅享主流AI工具!学习进阶更高效! 阅读详情

设计模式

设计模式是为了让程序(软件)具有更好的:

  1. 代码重用性,即相同功能的代码,不用多次编写;
  2. 可读性,即编程规范性,便于其他程序员的阅读和理解
  3. 可扩展性,即当需要增添其他新功能的时候,非常的方便;
  4. 可靠性,即添加了新的功能之后对原来的功能没有影响;
  5. 使程序呈现高内聚、低耦合的特性。

设计模式七大原则

设计模式原则,其实就是程序员在编程时,应该遵守的原则,也是各种设计模式的基础。
设计模式常用的七大原则有:

  1. 单一职责原则;
  2. 接口隔离原则;
  3. 依赖倒转原则;
  4. 里氏替换原则;
  5. 开闭原则;
  6. 迪米特法则;
  7. 合成复用原则;

详细介绍:

  1. 单一职责原则;

    比如说当创建交通工具类的时候,需要有一个run方法,让交通工具跑起来,对于不同的交通工具,其run方法是不同的,有“在路上跑”、“在水里开”、“在天上飞”,所以需要创建三个类,分别对应三种不同交通工具,这三个类拥有各自的run方法。

    以上对于类来说,一个类应该只负责一项职责,这就叫做单一职责原则

    但是,对于如此简单、只有一个方法的代码,完全可以使用一个类,在同一个类里面创建三个不同的run方法,给三种不同的交通工具使用。

    借此引出单一职责原则的注意事项和细节:

    • 降低类的复杂程度,一个类只负责一项职责;
    • 提高类的可读性,可维护性;
    • 降低变更引起的风险
    • 通常情况下,我们应该遵守单一职责原则,只有当逻辑足够简单,才可以在代码级违反单一职责原则;只有类中的方法足够少,才可以在方法级别保持单一职责原则。
  2. 接口隔离原则;

    客户端不应该依赖它不需要的接口,即一个类对另一个类的依赖应该建立在最小的接口上。

    比如说,有一个interface1接口里面包括五个方法:operation1()–operation5()。类A通过interface1接口依赖类B,用于实现接口中的1、2、3方法,类C通过interface1接口依赖类D,用于实现接口中的1、4、5方法。可以发现,interface1对于类A和类C来说都不是最小方法,它们都要去实现自己根本用不到的方法,这就违反了接口隔离原则。

    解决办法:将interface1分为interface1,用于实现方法operation1();interface2,用于实现方法operation2()和operation3();interface3,用于实现方法operation4()和operation5()。这样类A可以通过interface1和interface2实现对类B的依赖,类C可以通过interface1和interface3实现对类D的依赖。在这里插入图片描述

  3. 依赖倒转原则;

    依赖倒转原则指的是:
    1)高层模块不应该依赖低层模块,二者都应该依赖其抽象;
    2)抽象不应该依赖细节,细节应该依赖抽象;
    3)依赖倒转(倒置)的中心思想是面向接口编程
    4)依赖倒转原则基于这样的设计理念:相对于细节的多变性,抽象的东西要稳定的多。以抽象为基础搭建的架构要比以细节为基础搭建的结构稳定的多。在java中,抽象指的是接口或抽象类,细节指的是具体的实现类。
    5)使用接口或抽象类的目的是制定好规范,而不涉及任何的具体操作,把展现细节的任务交给实现类去完成。
    例子:用person接收不同类型的消息,设计一个接收消息的receiver,然后传递消息类型。

    依赖关系传递的三种方式:
    1)接口传递
    2)构造方法传递
    3)setter方式传递

    使用依赖倒转原则注意的事项和细节:
    1)低层模块尽量都要有抽象类或接口,或者两者都有,这样程序稳定性更好;
    2)变量的声明类型尽量是抽象类或接口,这样我们的变量引用和实际对象之间就存在一个缓冲层,有利于程序的扩展和优化;
    3)继承时遵循里氏替换原则。

  4. 里氏替换原则;

    OO中继承性的思考与说明:
    1)继承中包含这样一层含义:父类中凡是已经实现好的方法,实际上是在设计规范和契约,虽然它不强制所有的子类都必须遵循这些契约,但是如果子类对这些已经实现的方法作任意修改,则会破坏整个继承体系;
    2)继承在给程序设计带来便利的同时,也带来了弊端。比如说继承会给程序带来侵入性,程序的可移植性降低,增加对象之间的耦合性。如果一个类被另一个类所继承,那么当这个类需要修改时,需要考虑到继承它的子类。并且父类修改之后,所有涉及到的子类的功能可能产生故障;
    3)在编程中,如何正确的使用集成?–>里氏替换原则。

    基本介绍
    1)里氏替换原则(Liskov Substitution Principle)在1988年,由麻省理工学院的以为姓里的女士提出的。
    2)如果对每个类型为T1的对象o1,都有类型为T2的对象o2,使得以T1定义的所有程序P在所有的对象o1都代换成o2时,程序P的行为没有发生变化,那么类型T2是类型T1的子类型。换句话说,所有引用基类的地方必须能透明地使用其子类的对象
    3)在使用继承时,遵循里氏替换原则,在子类中尽量不要重写父类的方法
    4)里氏替换原则告诉我们,继承实际上让两个类耦合性增强了,在适当的情况下,可以通过聚合,组合,依赖来解决问题。.

    解决方法:
    1)在实际编程中,我们常常会通过重写父类的方法来完成新的功能,这样写起来虽然简单,但是整个程序的复用性会很差,特别是运用多态比较频繁的时候。
    2)通常的做法是:让原来的父类和子类都继承一个更通俗的基类,原有的继承关系去掉,用聚合、组合、依赖的方式来代替。

  5. 开闭原则;
    基本介绍
    1)开闭原则(Open Closed Principle)是编程中最基础、最重要的设计原则
    2)一个软件实体如类,模块和函数应该对扩展开放,对修改关闭用抽象构建框架,用实现扩展细节
    3)当软件需要变化时,尽量通过扩展软件实体的行为来实现变化,而不是通过修改已有的代码来实现变化。
    4)编程中遵循其它原则,以及使用设计模式的目的就是遵循开闭原则。

  6. 迪米特法则;
    基本介绍:
    1)一个对象应该对其他对象保持最少的了解;
    2)类与类关系越密切,耦合度越大;
    3)迪米特法则(Demeter Principle)又叫最少知道原则,即一个类对自己依赖的类知道的越少越好。也就是说,对于被依赖的类不管多么复杂,都尽量将逻辑封装在类的内部。对外除了提供的public方法,不对外泄露任何信息;
    4)迪米特法则还有个更简单的定义:只与直接的朋友通信;
    5)直接的朋友:每个对象都会与其他对象由耦合关系,只要两个对象之间有耦合关系,我们就说这两个对象之间是朋友关系。耦合的方式很多,依赖,关联,组合,聚合等。其中,我们称出现成员变量,方法参数,方法返回值中的类为直接的朋友,而出现在局部变量中的类不是直接的朋友。也就是说,陌生的类最好不要以局部变量的形式出现在类的内部

    迪米特法则注意事项和细节:
    1)迪米特法则的核心是降低类之间的耦合
    2)但是注意:由于每个类都减少了不必要的依赖,因此迪米特法则只是要求降低类间(对象间)耦合关系,并不是要求完全没有依赖关系

  7. 合成复用原则;
    尽量使用合成/聚合的方式,而不是使用继承。

C++设计模式面试通关手册 设计模式是C++面试的高频考点,几乎每场高级C++面试都会问到。但很多人只知道模式的名字,旦面试官要求手写实现或讨论应用场景,就露馅了。这篇把面试最常考的6种设计模式从原理到实现全部讲透。模式用途关键点单例全局唯实例私有构造 + 静态getInstance工厂创建对象封装创建逻辑观察者对多依赖通知机制策略算法可替换组合优于继承装饰器动态添加功能继承的替代方案适配器接口转换兼容不同接口设计模式不是语法,是思想。 阅读详情

相关推荐

文让你搞懂面向对象设计原则(单一职责原则开闭原则,里氏代换原则依赖倒转原则接口隔离原则合成复用原则迪米特法则)

面向对象设计原则 可维护性:指软件能够被理解,改正,适应及扩展的难易程度。 可复用性:指软件能够被重复使用的难易程度。 面向对象设计的目标之在于支持可维护性服用,方面需要实现设计方案或者源代码的服用,另方面 要确保系统能够易于扩展和修改,具有良好的可维护性。 面向对象设计原则为支持可维护性服用而诞生 指导性原则,非强制性原则。 每设计模式都符合个或多个面向对象设计原则,面向对象设计原则是用于评价 设计模式的使用效果的重要指标之。 面向对象设计原则

小徐的博客 1606

软件架构设计原则开闭原则依赖倒置原则单一职责原则接口隔离原则迪米特法则里氏替换原则、合成服用原则

1.开闭原则 (1)通过接口或抽象类约束扩展,对扩展进行边界限定; (2)参数类型、引用对象尽量使用接口或者抽象类,而不是实现类; (3)抽象层尽量保持稳定,旦确定就不允许修改; (4)将相同的变化封装在个接口或抽象类中; (5) 将不同的变化封装到不同的接口或抽象类中。 2.依赖倒置原则 依赖倒置原则(Dependence Inversion Principle)是程序要...

benpaodexin_l的博客 1744

设计模式七大原则, 单一职责原则,开闭原则, 里氏替换原则, 依赖倒置原则, 接口隔离原则,合成/聚合复用原则 迪米特原则

1.单一原则(Single Responsibility Principle) :个类或者个方法只负责项职责,尽量做到类的只有个行为原因引起变化; a、业务对象(BO business object)、业务逻辑(BL business logic)拆分; 2.里氏替换原则(LSP liskov substitution principle) :子类可以扩展父类的功能,但不能改变原有父类的功...

Light 2334

面向对象开发的六大原则单一职责、依赖倒置、里氏替换、开放闭合、合成聚合、接口隔离

单一职责:个类只做件事不做其他(高内聚) 依赖倒置:面向接口编程(spring的切面编程),就是声明的方法的参数类型、返回类型以及变量的引用类型,尽可能使用抽象类型而不是用具体类型(抽象类型可以被任何个子类型替代) 里式替换:任何时候子类都可以替换父类,子类继承父类肯定比父类的能力多,用能力多的类替换能力少的类 开放闭合原则:实体(比如人)对扩展开放对修改关闭,要做到开放闭合必须两点:...

大哥的叔的博客 7611

设计模式之六大原则——单一职责原则(SRP)

定义: 应该有且仅有个原因引起类的变更。 There should never be more than one reason for a class to change. 优点: 1、类的复杂性降低,实现什么职责都有清晰明确的定义; 2、可读性提高,复杂性减低,可读性当然提高; 3、可维护性提高,可读性提高,可维护性当然提高; 4、变更引起的风险减低,变更是必不可少的,如果...

weixin_30418341的博客 219

单一职责原则、开放封闭原则依赖倒转原则、里氏代换原则迪米特法则、合成/聚合复用原则

1.单一职责原则(SRP):个类而言,应该仅有个引起它变化的原因。 如果个类承担的职责太多,就等于把这些职责耦合在起,个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。 比如业务操作和日志记录类进行分开,界面和逻辑分开等等。职责分离,单一职责,更有利于维护和拓展。 2.开放-封闭原则: 类,模块,函数等等,应该可以拓展,但是不可以修改。 也就是:对于拓展是开放的,对于更改是封闭...

hello world 891

依赖倒转原则_面向对象设计原则总结(软件设计师必看)

《大数据和人工智能交流》头条号向广大初学者新增C 、Java 、Python 、Scala、javascript 等目前流行的计算机、大数据编程语言,希望大家以后关注本头条号更多的内容。 先声明:本文理论性强,大家看不懂不代表不能做开发,建议软件设计师级别以上的读者看,我也是看了湖南大学刘伟教授 文档之后感觉写的很好,很有感慨,特想分享给大家的,这次没有具体的例子,只有理论,具体的举例下次总结。...

weixin_39611765的博客 179

设计模式七大原则

从今天起,以后每天学点点设计模式的知识,同时把自己的学习记录在csdn记录下来,亦分享,亦查阅。 ...

刘一儿(嵌入式) 443

面向对象设计原则单一、开闭、里氏替换原则

昨天公司培训了面向对象设计原则单一、开闭、里氏替换原则,听过之后感触很多,因为刚进公司,之前的代码毫无原则可言,乱乱糟糟的,之后按照规范重构, 很痛苦,感觉自己的代码就像是坨翔,赶脚大姨夫捉急的都快提前了,代码规范这四个字真的是给我印象很深刻。 单一原则 定义:单一功能原则(Single responsibility principle)规定每个类都应该有单一的功能,...

464

设计模式精讲】30.总结 23 种设计模式(Summary of 23 Design Patterns)

先盘点 C++ 标准库与语言机制里已经落地的 12 种——迭代器是 STL 的地基、策略长在尖括号里、访问者化名 std::visit、智能指针正是 GoF 预言的智能引用代理——逐给出 API、原理映射与用法要点;再看标准库没有的 11 种,到 Boost、POCO、AOSP 等知名开源项目里看真身:Binder 工厂、Iostreams 过滤流、NotificationCenter 中介者。最后用张速查表收口:高频榜(哪些天天在用)、关联搭档表(哪些天然合作)、易混辨析表(哪些最常认错)。

码工许师傅 383

【AI编程系列】MCP 常用设计模式解读

Registry、Compose、BAM/Adapter、OpenAPI 和数据库是内部实现细节。它解决的是“工具契约、Agent 引导、路由和策略是否可审计、可发布、可回滚”。工具描述、资源内容、RAG 文档、Issue、README 和上游 API 返回的文本,都可能包含恶意指令。直接让 LLM 生成 SQL 的风险包括:字段口径错误、跨租户、任意 Join、资源失控、分页后误判 TopN。将“用户真正想完成的事”封装为个业务工具,由服务端完成跨 API、数据投影、权限收敛和流程控制。

Yangy的博客 135

设计模式精讲】28.访问者模式(Visitor)

本文给出访问者的 GoF 意图:在不改元素类的前提下为结构加新操作,核心机关是双重分派——accept 调 visit,visit 重载具体行为;C++98 版用 const 重载族贯穿只读访问,现代版给出 variant + std::visit 的无类形态与 overloaded 惯用法。文末对照 std::visit、Boost.Variant 的 static_visitor 与 POCO 的 SAX 处理器。这是 23 种模式的最后难。

码工许师傅 160

设计模式精讲】26.策略模式(Strategy)

篇埋的伏笔到此兑现——反面教材号 calcPrice 的 switch 又长回来了,二十七个分支,每加种定价全函数回归。本文从「算法平行可换」与「状态依次迁移」的分野讲起,给出策略模式的 GoF 意图:定义算法族、各自封装、彼此可互换,让算法独立于使用它的客户变化;C++98 版把定价规则做成可注入的策略对象(自带费率与门槛数据),现代版给出 std::function 策略、模板策略(STL 比较器的形态)、以及把两个策略组合成链的高阶函数。C++ 的特殊地位值得提:迭代器之后,策略是 STL

码工许师傅 420

设计模式精讲】24.观察者模式(Observer)

传感器每来个新样本,当前值面板、统计面板、告警模块都该刷新——直觉的写法是在 onSample 里逐个调用个面板,订阅者从此焊死在发布者体内,加块面板改次传感器。本文从 RG 的经典气象站讲起,给出观察者的 GoF 意图:对多依赖、状态变、全体自动通知——发布者对订阅者的认知降到「个接口」为止;C++98 版覆盖 notify 的重入副本、推与拉两种模型,现代版给出 std::function 槽位、RAII 订阅令牌与 weak_ptr 件套,把「观察者悬垂」这个 C++ 最著名的坑逐

码工许师傅 333

第四十二天学习心得

每次`DriverManager.getConnection()`都会创建新的物理连接,而**创建连接是非常耗时的操作**(TCP握手、身份验证等)。3. 连接池是性能优化的重要环:从自己手写连接池到理解原理,再到后续学习Druid、HikariCP等成熟框架,这条学习路径让我明白——**框架不是凭空产生的,而是把简单原理做到极致**。**这两步必须同时成功或同时失败**——这就是事务的意义。核心思路:重写`Connection.close()`方法,让它不是真正关闭连接,而是**归还到连接池**。

z23456d的博客 170

NestJS 后端开发实战:从设计模式到 CRUD 全栈

本文从工厂模式切入,讲解 NestJS 模块化架构、Controller 与 Service 分层,基于内存存储实现 Todos 增删改查 API,并配套单元测试,适合前端转后端开发者学习。

2503_93701293的博客 197

设计模式精讲】29.行为型模式总结与对比(Behavioral Patterns Summary)

行为型模式常被压缩成「堆回调技巧」,十种模式背起来像十道独立考题。其实按「各自要解决的问题」聚类,四个问题就装下了:组对象怎么对话(观察者/中介者/责任链)、变化的行为装进哪里(策略/模板方法/状态)、过去怎么留住(命令/备忘录)、结构怎么加工(迭代器/访问者/解释器)。同组是近亲,结构最像、最易混淆,本文逐组细说区别与联系,重点辨析「通信兄弟」;跨组模式几乎不会认错,却常串成流水线。再以横向对比表、决策树、组合案例、常见误判与评审清单收口。读完你能对着段交互代码说出:问题属于哪组,组内该

码工许师傅 273

设计模式精讲】27.模板方法模式(Template Method)

个后台任务类各自手写同套仪式——初始化、循环、异常捕获、收尾统计,份代码长得像又各缺角:有的忘了 try,有的收尾顺序不对,加「统超时」要改处将来 N 处。本文从仪式的复制讲起,给出模板方法的 GoF 意图:在基类固化算法骨架,把可变步骤延迟到子类——骨架非虚、钩子分「必填纯虚」与「可默认」两档;C++ 特有的 NVI 惯用法(公有非虚 + 私有虚)与模板方法互为表里,现代版补上 final、函数注入版(骨架 + 局部策略)与 CRTP 编译期骨架;好莱坞原则「别调用我们,我们会调用你」是它的

码工许师傅 236

设计模式精讲】25.状态模式(State)

订单能支付、能发货、能关闭——每种动作在每种状态下都有不同答案,直觉的实现是给每个方法配份全量 switch,于是「Created/Paid/Shipped」的分支在五个方法里各复制遍,加个状态全体加 case,合法的迁移图散落得没人能眼看清。本文从订单状态机的 switch 蔓延讲起,给出状态模式的 GoF 意图:状态变、行为整个换套,对象「看起来像换了个类」;状态对象无状态、全程共享份(与享元、单例同宗),迁移由当前状态自己决定;现代版给出迁移表与 C++17 的 variant 值语义

码工许师傅 290
下一篇: Java春招面试题第一篇
HappySundlut
博客等级 码龄7年 15粉丝 30原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值