设计模式六大原则之五：迪米特法则

最新推荐文章于 2025-08-10 08:32:47 发布
最新推荐文章于 2025-08-10 08:32:47 发布
阅读量514 收藏
点赞数 1
CC 4.0 BY-SA版权
文章标签： 设计模式
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/LaterEqualsNever1024/article/details/72520736
本文探讨了迪米特法则在程序设计中的应用及其影响。遵循这一原则有助于降低类间的耦合度并提高程序结构的清晰度，但同时也可能使程序变得更为复杂，增加维护难度。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

杜旭Duke
关注
设计模式系列课程07之【迪米特法则】
u014548782的专栏
05-06 1054
转自：http://blog.youkuaiyun.com/zhengzhb/article/details/7296930 定义：一个对象应该对其他对象保持最少的了解
ABAP-OO设计模式六大原则之六（迪米特法则）
SAP一叶知秋
02-08 190
概念：一个软件实体应当尽可能少的与其他实体发生相互作用。每一个软件单位对其他的单位都只有最少的知识，而且局限于那些与本单位密切相关的软件单位。迪米特法则的初衷在于降低类之间的耦合。由于每个类尽量减少对其他类的依赖，因此，很容易使得系统的功能模块功能独立，相互之间不存在（或很少有）依赖关系。迪米特法则不希望类之间建立直接的联系。如果真的有需要建立联系，也希望能通过它的友元类来转达。因此，应用迪米特法则有可能造成的一个后果就是：系统中存在大量的中介类，这些类之所以存在完全是为了传递类之间的相互调用关系——这在.
设计模式学习之——六大设计原则之五：迪米特法则
Mr.傅的专栏
03-18 1811
迪米特法则又称最少知识原则(Least Knowledge Principle, LKP) 解释1：一个对象应对其他对象有最少的了解 解释2：Only talk to your immedate friends（只与直接的朋友通信） 对类的低耦合提出明确要求：（4点） 1.只和朋友交流 eg：     老师教班长去清点班中女生人数（在老师类中初始化女生） 老师类：
设计模式（六）------设计模式六大原则（5）：迪米特法则
一些学习的记录，主要做个人知识总结整理
12-11 388
转载自：http://www.jianshu.com/p/14589fb6978e 揭秘迪米特法则 迪米特法则（Law of demeter,缩写是LOD）要求：一个对象应该对其他对象保持最少了解， 通缩的讲就是一个类对自己依赖的类知道的越少越好，也就是对于被依赖的类，向外公开的方法应该尽可能的少。 迪米特法则还有一种解释：Only talk to your immediate friend
设计模式六大原则（五）：迪米特法则(Law Of Demeter)
weixin_30338481的博客
11-29 184
定义： 一个对象应该对其他对象保持最少的了解。 问题由来： 类与类之间的关系越密切，耦合度越大，当一个类发生改变时，对另一个类的影响也越大。 解决方案： 尽量降低类与类之间的耦合。 PS: 自从我们接触编程开始，就知道了软件编程的总的原则：低耦合，高内聚。 无论是面向过程编程还是面向对象编程，只有使各个模块之间的耦合尽量的低，才能提高代码的复用率。 低耦合的优点不言而...
设计模式六大原则（5）：迪米特法则
java开发指南博客 【转载】
02-27 694
定义：一个对象应该对其他对象保持最少的了解。 问题由来：类与类之间的关系越密切，耦合度越大，当一个类发生改变时，对另一个类的影响也越大。 解决方案：尽量降低类与类之间的耦合。 自从我们接触编程开始，就知道了软件编程的总的原则：低耦合，高内聚。无论是面向过程编程还是面向对象编程，只有使各个模块之间的耦合尽量的低，才能提高代码的复用率。低耦合的优点不言而喻，但是怎么样编程才能做到低耦合呢？那正...
设计模式六大原则之：迪米特法则
在技术的广袤天地里，本博客如精准罗盘。剖析前沿科技，深掘代码奥秘，以精炼笔触，带您穿越复杂技术迷宫，速达知识彼岸。
08-19 1917
迪米特法则（Law of Demeter，简称LoD）‌，也称为最少知识原则，即只和朋友通信，不和陌生人说话。是面向对象设计的一个基本原则。一个对象应当尽可能少地了解其他对象，即对象之间的通信应该通过抽象层进行，以减少对象之间的直接依赖。迪米特法则的历史可以追溯到面向对象设计的早期实践，它是在1990年代由Erich Gamma等人从建筑设计领域引入到计算机科学中的。这个原则被视为一种重要的设计原则，用于指导如何设计和构建可维护和可扩展的软件系统。
Java 设计模式6大原则之(六)：迪米特法则
baipenggui_bo
05-18 1001
定义 一个软件实体应当尽可能少地与其他实体发生相互作用。 详细概述 迪米特法则又叫最少知道原则，通俗的来讲，就是一个类对自己知道的类知道的越少越好。也就是说，对于被依赖的类来说，无论逻辑多么复杂，都尽量的将逻辑封装在类的内部，对外除了提供的public方法，不对外泄漏任何信息。 问题由来 类与类之间的关系越密切，耦合度越大，当一个类发生改变时，对另一个类的影响也越大。迪米特法则可降低系统耦合度，使类与类之间保持松散的耦合关系。 其他定义形式 ...
六大设计模式原则-迪米特法则
热门推荐
qq_34222160的博客
03-16 1万+
一、迪米特法则定义 迪米特法则又最少知识原则，其定义如下： 迪米特法则(Law of Demeter, LoD)：一个软件实体应当尽可能少的与其他实体发生相互作用。 二、迪米特法则描述 如果一个系统满足迪米特法则，那么当其中一个软件实体发生变化时，就会尽量少的影响其他软件实体，扩展会相对容易，这是对软件实体之间通信的限制，迪米特法则要求限制软件实体之间通信的宽度和深度。迪米特法则可以降低系统的耦合度，使类与类之间保持松耦合状态。 迪米特法则还有几种定义形式，包括：不要和"陌生人"说话、只与你的直接朋友通信等
设计模式六大原则：迪米特法则详细说明和案例示范
J老熊
08-20 861
只与直接的朋友通信：一个对象应当只与那些与它关系密切的对象直接通信，而不应该依赖于太多的其他对象。避免过度依赖：对象之间的依赖关系应该尽量减少，避免形成复杂的依赖链。在实际开发中，这意味着我们应该设计简洁的接口，避免对象过度依赖于其他对象的内部细节，从而减少对象之间的耦合度。迪米特法则强调对象之间的交互应尽可能少，避免产生复杂的依赖关系。通过引入中介类或封装层，可以将依赖关系控制在合理的范围内，减少类之间的耦合度，提高系统的可维护性和可扩展性。
面向对象设计原则解析：迪米特法则与软件质量
"面向对象设计原则，包括迪米特法则在内的七大设计原则，是提升软件可维护性和可复用性的关键。这些原则旨在解决软件的僵硬性、脆弱性、低复用性和高黏度问题，同时也追求可扩展性、灵活性和可插入性。" 面向对象...
设计模式六大原则---迪米特法则（降低耦合度）
差池
06-26 2018
一.定义 迪米特法则（Law of Demeter，LoD）又叫作最少知识原则（Least Knowledge Principle，LKP)，产生于 1987 年美国东北大学（Northeastern University）的一个名为迪米特（Demeter）的研究项目，由伊恩·荷兰（Ian Holland）提出，被 UML 创始者之一的布奇（Booch）普及，后来又因为在经典著作《程序员修炼之道》（The Pragmatic Programmer）提及而广为人知。 迪米特法则的定义是：只与你的直接朋友交谈，
面向对象设计原则探索：迪米特法则与软件稳定性
郑州大学软件学院的赵哲教授在讲解设计模式时提到了这一原则，并将其与其他六大设计原则——单一职责原则、开-闭原则、里氏代换原则、依赖倒转原则、接口隔离原则、合成/聚合复用原则一起进行了介绍。" 迪米特法则...
六原则解析：设计模式中的单一职责到迪米特法则
本文主要探讨的是六项核心原则，它们分别是单一职责原则、开闭原则、接口隔离原则、里氏替换原则、依赖倒置原则和迪米特法则。这些原则旨在促进软件设计的可维护性、灵活性和可扩展性。 1. **单一职责原则（Single ...
Java设计模式总结
bthdnj的博客
08-07 322
《Java设计模式详解》概要 本文全面介绍了Java设计模式，分为四大部分： 设计模式概述 解释了设计模式的概念、核心要素和使用价值 重点阐述了三大设计原则：开放封闭、依赖倒置和单一职责 将23种设计模式分为创建型、结构型和行为型三大类 创建型模式 关注对象创建机制，包含单例、工厂、建造者和原型等模式 详细介绍了单例模式的多种实现方式及其适用场景 结构型模式 涉及对象组合方式，包括适配器、装饰器、代理等7种模式 每种模式都通过Java代码示例展示实现方式 行为型模式 处理对象间通信，涵盖观察者、策略、模板方
深入解析Go设计模式：命令模式实战
最新发布
liushen0528的博客
08-10 989
命令模式是一种行为型设计模式，它将请求封装为对象，实现调用者与接收者的解耦。该模式包含五个核心角色：命令接口、具体命令、接收者、调用者和客户端。实现时需定义命令接口和接收者，创建具体命令类绑定接收者，最后通过调用者执行命令。其优点在于职责解耦、扩展性强、支持复杂操作管理，但存在代码冗余、间接调用开销等缺点。在Go语言中应用时需注意错误处理和泛型限制。
B.10.01.5-电商系统的设计模式应用实战
m0_46221544的博客
08-09 585
问题描述：为了使用设计模式而使用，导致简单问题复杂化// ❌ 错误示例：简单的字符串拼接使用建造者模式// ✅ 正确做法：直接使用字符串拼接解决方案遵循KISS原则（Keep It Simple, Stupid）只在真正需要扩展性和灵活性时使用设计模式先写简单实现，在需要时再重构记住：设计模式是解决问题的工具，而不是炫技的手段。好的代码应该是简洁、清晰、可维护的，设计模式只是帮助我们达到这个目标的手段之一。
设计模式(二)——策略模式
记不住所以写下来
08-08 917
策略模式是一种行为型设计模式，通过定义算法族并封装为独立类，使它们可以相互替换，实现算法的灵活切换而不影响使用环境。本文以导航应用为例，演示了如何使用策略模式替代复杂的if-else逻辑：定义策略接口、实现具体策略类、创建持有策略引用的上下文类，以及客户端如何选择策略。相比状态模式，策略模式强调客户端控制算法选择，各策略独立无感知。该模式适用于算法可能变化、需要运行时切换的场景，能有效避免条件语句膨胀，符合开闭原则，但可能增加类数量。策略模式是管理算法变化的优雅解决方案。
设计模式中的行为模式
追赶时代的博客
08-07 932
本文系统解析了11种行为型设计模式的核心思想与典型应用。责任链模式适用于多级审批系统；命令模式支持撤销/重做操作；解释器模式处理语法解析；迭代器模式统一集合遍历；中介者模式简化对象交互；备忘录模式实现状态恢复；观察者模式建立发布订阅机制；状态模式将行为委托给状态对象；策略模式使算法可互换；模板方法定义算法骨架；访问者模式分离操作与对象结构。这些模式通过抽象行为和规范通信，有效解决了面向对象设计中的职责分配问题，广泛应用于现代框架如Spring、React等场景。理解其本质比记忆具体实现更重要。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值