Java设计原则 - 迪米特法则

手把手教您windows如何正确的开启局域网共享,如何解决“没权限、空密码访问等诸多问题”,含手动操作教程 + 傻瓜式一键设置工具(局域网共享+打印机管理),二选一总有一款能满足您! 😫 Windows共享总失败?别抓狂!这篇教程带你破解“空密码”访问的核心难题 🔑,四步搞定所有设置。文末还附赠“一键修复”神器 🚀,让文件共享丝滑如德芙! 阅读详情

六大设计原则

定义

一个对象应该对其他对象保持最少的了解

迪米特法则又叫最少知道原则,只与朋友说话,不要与陌生人说话。对类而言,哪些是朋友类呢?出现在成员变量、方法的输入输出参数中的类称为成员朋友类,而出现在方法体内部的类不属于朋友类。也就是说,方法体内的局部变量最好不是陌生类。

场景

我们设计一个场景,客户的空调坏了,联系商家叫维修师傅上门维修空调:

// 工具类
public class Tool {
    public String getName() {
        return "扳手";
    }
}
// 维修师傅
public class Worker {
    public void doWork(Tool tool) {
        System.out.println("维修师傅用" + tool.getName() + "在维修空调");
    }
}
// 商家
public class Business {
    private Worker worker;
    public Business() {
        worker = new Worker();
    }
    public void command() {
        Tool tool = new Tool();
        worker.doWork(tool);
    }
}
// 客户
public class Client {
    public static void main(String[] args) {
        Business business = new Business();
        business.command();
    }
} 

我们重点分析商家类Business,它的直接朋友类是维修师傅类Worker(出现在成员变量中),可是command方法内却出现结果陌生的工具类Tool。商家类Business其实并不需要知道工具类Tool的存在,他只与维修师傅类Worker打交道就行,至于师傅用什么工具,他不care的。
所以,我们需要修改一下:

// 维修师傅
public class Worker {
    public void doWork() {
        Tool tool = new Tool();
        System.out.println("维修师傅用" + tool.getName() + "在维修空调");
    }
}
// 商家
public class Business {
    private Worker worker;
    public Business() {
        worker = new Worker();
    }
    public void command() {
        worker.doWork();
    }
}

这样修改之后,商家类Business就不再依赖工具类Tool了,因为根本不需要知道。

但是也不能和朋友类过于“亲密”,知道就好,还是延续上面的例子说明。维修空调可能需要很多工具,除了扳手,还有螺丝刀,清洁工具等。

// 工具接口
public interface Tool {
    String getName();
}
// 扳手工具类
public class BanShou implements Tool {
    return "扳手";
} 
// 螺丝刀工具类
public class LuoSiDao implements Tool {
    return "螺丝刀";
}
// 清洁工具工具类
public class QingJieTool implements Tool {
    return "清洁工具";
}
// 维修师傅
public class Worker {
    // 用扳手修空调
    public boolean doWork1() {
        BanShou tool = new BanShou();
        System.out.println("维修师傅用" + tool.getName() + "在维修空调,没修好");
        return false;
    }
    // 用螺丝刀修空调
    public boolean doWork2() {
        LuoSiDao tool = new LuoSiDao();
        System.out.println("维修师傅用" + tool.getName() + "在维修空调,没修好");
        return false;
    }
    // 用清洁工具修空调
    public boolean doWork3() {
        QingJieTool tool = new QingJieTool();
        System.out.println("维修师傅用" + tool.getName() + "在维修空调,修好了");
        return false;
    }
}
// 商家
public class Business {
    private Worker worker;
    public Business() {
        worker = new Worker();
    }
    public void command() {
        if (worker.doWork1()) {
            System.out.println("维修师傅使用扳手修好了空调");
        } else if (worker.doWork2()) {
            System.out.println("维修师傅使用螺丝刀修好了空调");
        } else if (worker.doWork3()) {
            System.out.println("维修师傅使用清洁工具修好了空调");
        } else {
            System.out.println("维修师傅修不好空调了");
        }
    }
}

例子中,商家类Business的确只与朋友类Worker说话,但是不觉得商家类Business知道管太多了吗?还要“指挥”维修师傅类Worker怎么去修。这是因为维修师傅类Worker“告诉”商家类Business太多“秘密”了,也就是公布太多方法了!既然知道原因,那就把方法私有化,自己知道就行:

// 维修师傅
public class Worker {
    // 用扳手修空调
    private boolean doWork1() {
        BanShou tool = new BanShou();
        System.out.println("维修师傅用" + tool.getName() + "在维修空调,没修好");
        return false;
    }
    // 用螺丝刀修空调
    private boolean doWork2() {
        LuoSiDao tool = new LuoSiDao();
        System.out.println("维修师傅用" + tool.getName() + "在维修空调,没修好");
        return false;
    }
    // 用清洁工具修空调
    private boolean doWork3() {
        QingJieTool tool = new QingJieTool();
        System.out.println("维修师傅用" + tool.getName() + "在维修空调,修好了");
        return false;
    }
    // 修空调
    public void doWork() {
        if (doWork1()) {
            System.out.println("维修师傅使用扳手修好了空调");
        } else if (doWork2()) {
            System.out.println("维修师傅使用螺丝刀修好了空调");
        } else if (doWork3()) {
            System.out.println("维修师傅使用清洁工具修好了空调");
        } else {
            System.out.println("维修师傅修不好空调了");
        }
    }
}
// 商家
public class Business {
    private Worker worker;
    public Business() {
        worker = new Worker();
    }
    public void command() {
        worker.doWork();
    }
}

维修师傅值提供一个方法,就是维修空调,至于怎么维修,那就是维修师傅自己的事了!这样,即使维修师傅更换维修方式,也和商家无关,商家类Business不用做任何修改!

小结

综上,最少知道原则有2个核心思想:

  1. 尽量不要和陌生类产生依赖关系;
  2. 尽量不要知道朋友类太多细节;

总得来说,迪米特法则的主要目的是减少类没必要的依赖,降低类之间的耦合度。

CLAHE 算法学习 matlab 概念可参考: CLAHE (Contrast Limited Adaptive Histogram Equalization)算法学习CLAHE具体实现主要包括6个步骤。1):分块。将输入图像划分为大小相等的不重叠子块,每个子块含有的像素数为M。参考示例为8×8块。 2):计算子块直方图。 3):计算剪切阈值clipLimit 4):像素点重分配。对每个子块,使用步骤三中多余的像素重新分配。 5):直方图均衡。 6):像素点灰度值重构。(源码中采用了双线性插值) http://www.realtimer 阅读详情

相关推荐

【Claude Code】Claude Code 使用指南

本文介绍了AI编码助手Claude的基础和进阶操作指南。基础部分涵盖启动命令、模式切换(自动编辑/Plan/Yolo模式)、资源监控等核心功能,重点讲解了斜杠命令的使用方法。进阶操作详细说明了CLAUDE.md文件的创建与管理,包括项目规范、代码风格等内容的配置,以及如何通过该文件建立持久上下文。同时提醒了使用过程中的安全风险,建议通过配置文件限制AI对关键代码的访问权限。全文提供了完整的操作指引和安全建议,帮助开发者高效安全地使用Claude进行编码辅助。

大家好,我是敖云岚,一个沉迷代码的 “技术玩家”。擅长 Java、C++ 开发,对 MySQL、Redis、RabbitMQ 等技术也颇有研究。博客里既有硬核技术干货,也有诙谐幽默的编程日常分享。愿和你一起,笑着学技术,快乐敲代码! 1万+

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

Java设计模式之七大设计原则 本文对Java设计模式中的七大设计原则进行汇总介绍,提炼最核心的概念。 设计模式总结笔记 一、设计模式七大原则 设计模式的目的: 代码可重用性:相同功能的代码,不用多次编写。 可读性:编程规范性,便于其他程序员的阅读和理解。 可扩展性:当需要增加新的功能的时候,非常方便,称为可扩展性。 可靠性:当我们新增功能后,对原来的功能没有影响。 使程序呈现高内聚、低耦合特性。 1.1、单一职责原则 不遵守单一职责原则: 对类来说的,就是一个类应该只负责一项职责。 比如:Us

qq_49529322的博客 1万+

电子设计实战:用MOS管手把手搭建D触发器电路(含时序分析避坑指南)

本文详细介绍了如何使用MOS管从零开始搭建D触发器电路,重点解析了建立时间和保持时间等关键时序参数对电路稳定性的影响。通过实测波形分析和避坑指南,帮助电子工程师掌握D触发器的实际搭建技巧与优化方法,提升数字电路设计的可靠性。

x1y2z的博客 1161

java设计原则

单一职责原则:对一个类而言,应当只有一个引起它变化的原因,永远不要让一个类存在多个改变的理由。因此,一个类应该只做一个职责相关的业务,不要把过多的职责放在同一个类中完成。

Temptatn的博客 754

Gartner 2025 中国网络安全成熟度曲线深度解读:AI 安全如何重构防御逻辑

2025 年 Gartner 中国网络安全技术成熟度曲线的发布,标志着国内网络安全领域正式进入 “AI 原生防御” 时代。这份聚焦中国市场特性的报告清晰揭示:网络安全的核心命题已从 “防御 AI 驱动的攻击” 演进为 “保障 AI 系统自身安全与业务协同”,AI 安全技术正成为重构企业防御体系的核心引擎。

KKKlucifer的博客 1387

【OpenCV3】cv::compare()使用详解

cv::compare()主要用于两个图像之间进行逐像素的比较,并输出比较的结果。具体用法如下: cv::compare() bool cv::compare( cv::InputArray src1, // 输入数组1 cv::InputArray src2, // 输入数组2 cv::OutputArray dst, // 输出数组 int cmpop // 比较操作子,见下表 ...

guduruyu的专栏 9760

Java 6大设计原则28大设计模式

6大设计原则: 1. 单一职责原则 单一职责原则的英文名称是Single Responsibility Principle,简称是SRP(There should never be more than one reason for a class to change.) 见名知意,充斥着满满的争议,需求的更替,版本的迭代,场景的复杂,种种都能导致这个被破坏,但是把出发点是好的,单一意味着简单,简单意味着易懂,而后易维护、节省人力、成本、增加稳定性;但是场景复杂时就类就多了,em...;仁者见仁智者见

z3191595的博客 4974

QOpenGL入门教程(二)—— 第一个QOpenGLWidget程序

终于到了实际操作的环节了,这一章我们要做的是: 创建OpenGL窗口 创建并编写着色器程序 为着色器程序装配顶点数据 启动渲染管线进行绘图 第一步:创建新项目 首先,我们使用Qt创建一个常规的QWidget项目,建议不要勾选ui设计器(个人习惯,笔者不太习惯于使用ui来设计) 第二步:创建QOpenGLWidget并实现三个虚函数 QOpenGLWidget Qt5.4之前,Qt可以通过一个QGLWidget类来创建OpenGL窗口,但由于opengl的发展,在5.4版本的时候,Qt提供

ItaLink 1万+

java 7大设计原则

解释:B无意中重写的父类的func1方法, 原本func1 是 num1 - num2,重写后 变成 相加, 这样 如果是无意识的话,程序员本来要做 func1的相减功能,但是结果却是相加。一个类 对自己依赖的类知道的越少越好。1、父类中凡是已经实现好的方法,虽然他不强制要求所有的子类必须遵循这些契约,但是如果子类对这些已经实现的方法任意修改,就会对整个继承体系造成破坏。2、如果一个类被其他类所继承,则当这个类需要任意修改,就必须考虑到所有的子类,并且父类修改后,所有涉及到子类的功能都可能产生故障。

wdquan19851029的专栏 1842

linux驱动由浅入深系列:块设备驱动之一(高通eMMC分区实例)

linux驱动由浅入深系列:块设备驱动之一(高通eMMC分区实例)linux驱动由浅入深系列:块设备驱动之二(块设备驱动结构分析)块设备驱动的模型还是基本基于字符设备驱动的,可以简单理解为块设备仅仅增加了操作缓冲区,对用户请求顺序进行队列重拍等等。字符设备驱动的相关分析可以查看本博客相关的博文。 按照本博客的行文习惯,在具体分析块设备驱动代码之前,我们会从整体上了解一下研究对象的特征,以及用户空间...

Radia的专栏 1万+

Ubuntu零基础教学-如何把Ubuntu20.04界面从英文修改为中文?| 超级详细,建议收藏

带你如何把Ubuntu20.04界面从英文修改为中文?| 超级详细,建议收藏

**My Coding Family** 5340

Java 设计原则:七种方法帮助你更好地设计软件

总结一下,设计模式中的7大原则是:单一职责原则、开放封闭原则、里氏替换原则、依赖倒转原则、迪维恩原则、合成复用原则和接口隔离原则。这些原则都是在软件设计中常用的原则,它们可以帮助我们在设计软件系统时避免一些常见的问题。

qq_35090943的博客 1341

YOLOv8自定义训练:车牌识别全流程(从标注到推理,附可视化代码)

车牌检测全流程实践指南 摘要:本文详细介绍了基于YOLOv8的车牌检测完整实现方案。针对车牌检测中的三大难点(小目标、多角度、光照变化),提供了从数据准备到模型部署的全流程解决方案。重点包括:1)数据采集与标注规范;2)针对小目标的YOLOv8模型优化配置;3)K-means锚框聚类方法;4)训练参数调优策略。通过实际验证,该方法可获得95%以上的检测准确率,并附有完整的代码实现和可视化工具,便于开发者快速复现应用。 (字数:149字)

专注于Python爬虫开发,分享爬虫技巧、项目实战与反爬经验,使用Scrapy、BeautifulSoup等工具,解决数据抓取难题。 850

【Java设计模式 经典设计原则】七 LOD迪米特法则

SRP原则侧重高内聚,指导类功能的设计要单一,LOD法则侧重低耦合,指导类间依赖关系要松耦合,ISP原则是从调用者的角度出发确保接口的设计具备对调用者有良好的隔离性。基于接口而非实现编程思想也是从调用者的角度出发确保稳定的依赖和可插拔的实现。总的来说SRP原则、ISP原则、LOD法则以及基于接口而非实现编程思想的目标都是实现代码的高内聚低耦合,提高代码的可扩展性、可读性和可维护性。

MaoLin Tian's Blog 794

VC中sqlite的使用

在VC中对sqlite的使用,实现数据库大批数据的快速插入,读取数据库中的数据在ListCtrl中显示

IDEA的使用指南

IDEA基于java的使用手册,可以最快速的上手,在使用中不断的丰富自己的使用技巧.

Java设计模式之设计原则-迪米特法则 (LoD)

????文章示例代码???? 迪米特法则也叫做最少知道原则。 附链 你也可以在这些平台阅读本文: 语雀 个人博客 定义 一个对象应该对其他对象保持最少的了解。 在《Head First 设计模式》一书中,针对该原则也强调:只和你的密友交流。 在程序中,出现在成员变量、方法的输入、输出参数中的类我们可以称之为成员朋友类,而出现在方法体内部的类不属于朋友类。 这些个成员朋友类的对象和当前对象之间存在关联、...

Horace's Blog 418

jre9下载 jdk9

(Java SE Runtime Environment 9.0) 9.0u175 官方最新版 【x86|x64】

【Java 设计模式】设计原则之迪米特法则

迪米特法则是由荷兰计算机科学家伊恩·荷尔姆·迪米特(Ian Holland Demeter)于1987年提出的。它规定一个对象应该对其他对象有最少的了解,即一个类不应该知道太多关于其他类的内部细节。迪米特法则有一个简洁的表述:“只与你的直接朋友通信,不跟陌生人说话”,其中“直接朋友”指的是当前对象的成员、方法参数、方法返回值中的对象。迪米特法则是一项有助于降低类之间耦合性的基本原则。通过遵循这一原则,我们可以创建更加灵活、可维护和可扩展的面向对象系统。

好久不见的流星 1834

Probability and Statistics - 4th edition

Probability and Statistics - 4th edition

JAVA设计原则:迪米特法则

迪米特法则 迪米特法则(Law of Demeter )又叫做最少知识原则,也就是说,一个对象应当对其他对象尽可能少的了解。狭义的解释为,如果两个类不必彼此直接通信,那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一类的某一个方法的话,可以通过第三者转发这个调用。   一、和陌生人讲话 这里someone,直接跟stranger进行通信,通过public void play(St...

Derrick 309

java中七大设计原则之迪米特法则详解

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

qq_49529322的博客 405

迪米特法则 java_Java设计原则—迪米特法则(转)

定义:迪米特法则(Law of Demeter,LoD)也称为最少知识原则(Least Knowledge Principle,LKP)。一个对象应该对其他对象有最少的了解。通俗地讲,一个类应该对自己需要耦合或调用的类知道得最少,你(被耦合或调用的类)的内部是如何复杂都和我没关系,那是你的事情,我就知道你提供的public方法,我就调用这么多,其他的一概不关心。含义:只和朋友交流朋友类的定义是这样...

weixin_39872222的博客 118

Java面向对象设计原则6——迪米特法则

在我们学习面向对象编程的时候,总会出现一些问题,好比以前刚刚写好的代码,上线测试可以、正常运行,突然有一天说要加一个功能,改完之后,发现以前正常运行的功能不能用了,类似这样的问题有好多好多,为了避免类似的事件发生,程序员一定要根据这些原则去开发程序。 我们一个一个来学习,今天来学习7大面向对象设计原则之一,迪米特法则。 迪米特法则: 迪米特法则(Law of Demeter,LoD)又叫作最...

胖子胖子大胖子的博客 1153

Java设计原则——迪米特法则

我们一定要给自己提出这样的任务:第一,学习,第二是学习,第三还是学习。 学习从来无捷径,循序渐进登高峰。 目录一、基本介绍二、应用实例1、示例一2、示例二三、迪米特法则 一、基本介绍 一个对象应该对其他对象保持最少的了解 类与类关系越密切,耦合度越大 迪米特法则(Demeter Principle)又叫最少知道原则,即一个类对自己依赖的类知道的越少越好。也就是说,对于被依赖的类不管多么复杂,都尽量将逻辑封装在类的内部。对外除了提供的public 方法,不对外泄露任何信息 迪米特法则还有个更简单的定义.

怪咖@的博客 550

Java设计原则—迪米特法则(转)

定义: 迪米特法则(Law of Demeter,LoD)也称为最少知识原则(Least Knowledge Principle,LKP)。 一个对象应该对其他对象有最少的了解。通俗地讲,一个类应该对自己需要耦合或调用的类知道得最少,你(被耦合或调用的类)的内部是如何复杂都和我没关系,那是你的事情,我就知道你提供的public方法,我就调用这么多,其他的一概不关心。 含义: 只和朋友交流 朋...

翎野君的博客 126

java 迪米特_Java设计原则—迪米特法则(转)

定义:迪米特法则(Law of Demeter,LoD)也称为最少知识原则(Least Knowledge Principle,LKP)。一个对象应该对其他对象有最少的了解。通俗地讲,一个类应该对自己需要耦合或调用的类知道得最少,你(被耦合或调用的类)的内部是如何复杂都和我没关系,那是你的事情,我就知道你提供的public方法,我就调用这么多,其他的一概不关心。含义:只和朋友交流朋友类的定义是这样...

weixin_42492000的博客 221

Java六大设计原则-迪米特法则

迪米特法则 定义 一个对象应该对其他对象保持最少的了解。 问题由来 类与类之间的关系越密切,耦合度越大,当一个类发生改变时,对另一个类的影响也越大。 解决方案 尽量降低类与类之间的耦合。 自从我们接触编程开始,就知道了软件编程的总的原则:低耦合,高内聚。无论是面向过程编程还是面向对象编程,只有使各个模块之间的耦合尽量的低,才能提高代码的复用率。低耦合的优点

Linux_para的专栏 420

[java设计原则]--迪米特法则

迪米特法则 定义 一个对象一个对其他对象保持最少的了解。 又叫最少知道原则。 强调 尽量降低类与类之间的耦合。 只和朋友交流,不和陌生人说话。朋友:出现在成员变量、方法输入、输入参数中的类称为成员朋友类,而且出现在方法体内部的类不属于朋友类。 优点 降低类之间的耦合。 举例 public class Test { public static void main(String[...

空樽邀月的博客 233

Java设计原则——从“最少知道”到“高内聚低耦合”:迪米特法则的实战精讲

本文深入解析Java设计原则中的迪米特法则(最少知道原则),通过实战案例展示如何实现高内聚低耦合的代码设计。从识别违反法则的代码坏味道到重构实战,再到微服务架构中的特殊应用,全面讲解如何合理运用这一原则提升代码质量与可维护性。

weixin_34302561的博客 441
上一篇: Java设计原则 - 接口隔离原则
下一篇: Java设计原则 - 开闭原则
JohanMan
博客等级 码龄10年 72粉丝 131原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明:

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

余额充值