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

概念

迪米特法则解决类与类之间耦合度问题，如果类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是陌生人。

使用

迪米特法则解决了类之间耦合度问题，使得类与类之间的接口通讯变得简单，提高了可维护性，但同时也增加了调用层次和复杂度。但以下情况一定要使用迪米特法则规避风险。

1. 使用第三方组件或者控件时，增加一个包装器的类，使得调用方和第三方组件完全脱耦，如桌面程序中使用XP style一组控件属于第三方控件，每个控件增加一个包装器类，无论什么时间，XP style控件不能使用时，如：免费突然变收费，我们只需要修改包装器类中代码即可。
2. 对于预期会发生较大变化的模块，增加一个外观层，简化和稳定高层模块的调用关系，与不稳定部分脱耦。
3. 对付团队新成员或代码质量较差程序员，增加一个外观层，避免因频繁的修改，造成整个程序挂掉。

拓展

1. 意思就是降低各个对象之间的耦合，提高系统的可维护性；
2. 迪米特法则是一种设计思想，不仅仅体现在对象与对象的之间的耦合度问题上，而是广泛应用到各种分层结构中层与层之间的关系，每个层之间形成一种隔离关系，调用无需了解层内部及更下一级层的调用关系。如MVP模式，P将M和V结合起来，使得M和V都可以独立的进行变化，任何一方的变化仅影响到P层代码的变化。
3. 前端开发时使用独立出来的API就是迪米特法则的要求，如：

 var api = {
   adminLogin: (param) => post(apiBase+"/sys/login", param),
   userLogin: (param) => post(apiBase+"/sys/weblogin", param),
   }

页面调用时只需要调用api中定义的adminLogin方法，当后端定义的路劲名apiBase、方法名login发生变化时，只修改api即可，不会影响到调用页面的代码
5. 设计模式中对象适配器、代理模式、门面模式等均体现了迪米特法则的思想。