概念
迪米特法则解决类与类之间耦合度问题，如果类A调用了B类的某一个方法，则这两个类就形成了一种紧耦合的方式，当B类这个方法发生变化时，一定会影响A类的执行结果。迪米特法则要求每一个类尽可能少的与其他类发生关系，也就是尽可能少的让其他类发生变化时，对其代码的执行结果产生的影响降到最低。
典型情况：A类调用B类的方法，B类和C类是一种关联关系，如果A类通过B类所持有的C类对象直接调用C类的方法，则A类和C类同时拥有强耦合的关系。代码如下：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
public class B { public C c = new C();}public class C { public void fun() { //相关代码 }}public class A { public void show(){ B b = new B(); b.c.fun(); }} |
这种调用A和C之间形成一种强耦合，当C中fun代码发生变化时，一定会影响到A，不符合迪米特法则。按照迪米特法则的要求可修改为：
|
1
2
3
4
5
6
7
8
9
10
11
12
|
public class B { private C c = new C(); public void fun(){ c.fun(); }}public class A { public void show(){ B b = new B(); b.fun(); }} |
A和C代码完全脱耦，当C的fun代码发生变化时，只需要修改类B中fun代码；当A中业务逻辑发生变化时，需要修改B中fun代码，也只需修改B中代码，和C中代码无关。
迪米特法则又叫做最少知识原则(LKP),就是说,一个对象应当对其他对象有尽可能少的了解。通俗的讲“不和陌生人讲话，只和朋友交流”，上述示例中类A和类B是朋友，和类C是陌生人。
使用
迪米特法则解决了类之间耦合度问题，使得类与类之间的接口通讯变得简单，提高了可维护性，但同时也增加了调用层次和复杂度。但以下情况一定要使用迪米特法则规避风险。
1.使用第三方组件或者控件时，增加一个包装器的类，使得调用方和第三方组件完全脱耦，如桌面程序中使用XP style一组控件属于第三方控件，每个控件增加一个包装器类，无论什么时间，XP style控件不能使用时，如：免费突然变收费，我们只需要修改包装器类中代码即可。
2.对于预期会发生较大变化的模块，增加一个外观层，简化和稳定高层模块的调用关系，与不稳定部分脱耦。
3.对付团队新成员或代码质量较差程序员，增加一个外观层，避免因频繁的修改，造成整个程序挂掉。
拓展
1.意思就是降低各个对象之间的耦合，提高系统的可维护性；
2.迪米特法则是一种设计思想，不仅仅体现在对象与对象的之间的耦合度问题上，而是广泛应用到各种分层结构中层与层之间的关系，每个层之间形成一种隔离关系，调用无需了解层内部及更下一级层的调用关系。如MVP模式，P将M和V结合起来，使得M和V都可以独立的进行变化，任何一方的变化仅影响到P层代码的变化。
3.前端开发时使用独立出来的API就是迪米特法则的要求，如：
|
1
2
3
4
|
var api = { adminLogin: (param) => post(apiBase+"/sys/login", param), userLogin: (param) => post(apiBase+"/sys/weblogin", param), } |
页面调用时只需要调用api中定义的adminLogin方法，当后端定义的路劲名apiBase、方法名login发生变化时，只修改api即可，不会影响到调用页面的代码
4. 设计模式中对象适配器、代理模式、门面模式等均体现了迪米特法则的思想。
以上就是java面向对象设计原则之迪米特法则分析详解的详细内容，更多关于java面向对象设计原则的资料请关注服务器之家其它相关文章！
原文链接：https://blog.csdn.net/guoyp2126/article/details/114074525
