概念
迪米特法则解决类与类之间耦合度问题,如果类A调用了B类的某一个方法,则这两个类就形成了一种紧耦合的方式,当B类这个方法发生变化时,一定会影响A类的执行结果。迪米特法则要求每一个类尽可能少的与其他类发生关系,也就是尽可能少的让其他类发生变化时,对其代码的执行结果产生的影响降到最低。
典型情况:A类调用B类的方法,B类和C类是一种关联关系,如果A类通过B类所持有的C类对象直接调用C类的方法,则A类和C类同时拥有强耦合的关系。代码如下:
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,不符合迪米特法则。按照迪米特法则的要求可修改为:
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是陌生人。
使用
迪米特法则解决了类之间耦合度问题,使得类与类之间的接口通讯变得简单,提高了可维护性,但同时也增加了调用层次和复杂度。但以下情况一定要使用迪米特法则规避风险。
- 使用第三方组件或者控件时,增加一个包装器的类,使得调用方和第三方组件完全脱耦,如桌面程序中使用XP style一组控件属于第三方控件,每个控件增加一个包装器类,无论什么时间,XP style控件不能使用时,如:免费突然变收费,我们只需要修改包装器类中代码即可。
- 对于预期会发生较大变化的模块,增加一个外观层,简化和稳定高层模块的调用关系,与不稳定部分脱耦。
- 对付团队新成员或代码质量较差程序员,增加一个外观层,避免因频繁的修改,造成整个程序挂掉。
拓展
- 意思就是降低各个对象之间的耦合,提高系统的可维护性;
- 迪米特法则是一种设计思想,不仅仅体现在对象与对象的之间的耦合度问题上,而是广泛应用到各种分层结构中层与层之间的关系,每个层之间形成一种隔离关系,调用无需了解层内部及更下一级层的调用关系。如MVP模式,P将M和V结合起来,使得M和V都可以独立的进行变化,任何一方的变化仅影响到P层代码的变化。
- 前端开发时使用独立出来的API就是迪米特法则的要求,如:
var api = {
adminLogin: (param) => post(apiBase+"/sys/login", param),
userLogin: (param) => post(apiBase+"/sys/weblogin", param),
}
页面调用时只需要调用api中定义的adminLogin方法,当后端定义的路劲名apiBase、方法名login发生变化时,只修改api即可,不会影响到调用页面的代码
5. 设计模式中对象适配器、代理模式、门面模式等均体现了迪米特法则的思想。