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

概念

迪米特法则解决类与类之间耦合度问题,如果类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. 设计模式中对象适配器、代理模式、门面模式等均体现了迪米特法则的思想。

你可能感兴趣的:(程序设计,面向对象编程)