迪米特法则

定义:一个对象应该对其他对象有最少的了解。

通俗的讲:一个类对自己需要耦合或调用的类知道的最少,你(被耦合或调用的类)的内部是如何复杂和我没有关系,我就知道你提供的public方法,我只调用这些方法,其它的我不关心。

迪米特原则的具体要求

迪米特原则还有一个解释:Only talk to your immediate friends(只与直接朋友通信)。
什么叫直接朋友呢?每个对象都必然会与其他对象有耦合关系,两个对象之间的耦合就成为朋友关系,这种关系类型有很多,例如:组合,聚合,依赖等。朋友类也可以这样定义:出现在成员变量,方法的输入输出参数中的类,称为朋友类。

上体育课,我们经常有这样一个场景:
体育老师上课前要体育委员确认一下全班女生到了多少位,也就是体育委员清点女生的人数。类图如下:

老师类:

public class Teacher{
  //老师对体育委员发一个命令,让其清点女生人数
  public void command(GroupLeader groupLeader){
     List<Girl> listGirls = new ArrayList();
     //初始化女生
     for(int i=0;i<20;i++){
       listGirls.add(new Girl());
     }
     //告诉体育委员开始清点女生人数
     groupLeader.countGirls(listGirls);
  }
}

体育委员类:

public class GroupLeader{
  //清点女生数量
  public void countGirls(List<Girl> listGirls){
     System.out.println("女生人数是:"+listGirls.size());
  }
}

女生类:

publci class Girl{
}

场景类:

public class Client{
   public static void main(Strings[] args){
      Teacher teacher = new Teacher();
      //老师给体育委员发清点女生人数的命令
      teacher.command(new GroupLeader());
   }

}

我们再回头看Teacher类,Teacher类只有一个朋友类GroupLeader,Girl类不是朋友类,但是Teacher与Girl类通信了,这就破坏了Teacher类的健壮性,Teacher类的方法竟然与一个不是自己的朋友类Girl类通信,这是不允许的,严重违反了迪米特原则。

我们对程序进行如下修改,将类图修改如下:

修改后的老师类:

public class Teacher{
  //老师对体育委员发一个命令,让其清点女生人数
  public void command(GroupLeader groupLeader){
     //告诉体育委员开始清点女生人数
     groupLeader.countGirls();
  }
}

修改后的体育委员类:

public class GroupLeader{
   private List<Girl> listGirls;
   public GroupLeader(List<Girl> listGirls){
      this.listGirls = listGirls;
   }
  //清点女生数量
  public void countGirls(){
     System.out.println("女生人数是:"+listGirls.size());
  }
}

修改后的场景类:

public class Client{
   public static void main(Strings[] args){
     //产生女生群体
     List<Girl> listGirls = new ArrayList<Girl>();
     //初始化女生
     for(int i=0;i<20;i++){
       listGirls.add(new Girl());
     }

      Teacher teacher = new Teacher();
      //老师给体育委员发清点女生人数的命令
      teacher.command(new GroupLeader(listGirls));
   }
}

对程序修改,把Teacher中对Girl群体的初始化移动到场景类中,同时在GroupLeader中增加对Girl的注入,避开了Teacher类对陌生类Girl的访问,降低了系统间的耦合,提高了系统的健壮性。

总结

迪米特原则的核心观念就是类间解耦,弱耦合,只有弱耦合后,类的复用率才可以提高。其结果就是产生了大量的中转或跳转类,导致系统复杂,为维护带来了难度。所以,我们在实践时要反复权衡,即要让结构清晰,又做到高内聚低耦合。

时间: 2024-12-16 06:21:51

迪米特法则的相关文章

迪米特法则详解--七大面向对象设计原则(6)

迪米特法则的来源: 迪米特法则又叫最少知道原则,最早是在1987年由美国Northeastern University的Ian Holland提出.类与类之间的关系越密切,耦合度越大,当一个类发生改变时,对另一个类的影响也越大.于是就提出了迪米特法则.通俗的来讲,就是一个类对自己依赖的类知道的越少越好.也就是说,对于被依赖的类来说,无论逻辑多么复杂,都尽量地的将逻辑封装在类的内部,对外除了提供的public方法,不对外泄漏任何信息. 迪米特法则的简单定义:     只与直接的朋友通信. 首先来解

面向对象设计原则之五:迪米特法则

迪米特法则 迪米特法则(Law of Demeter)又叫最少知识原则(Least Knowledge Principle LKP),就是说一个对象应当对其他对象有尽可能少的了解,不和陌生人说话. 对面向对象来说,一个软件实体应当尽可能的少的与其他实体发生相互作用.每一个软件单位对其他的单位都只有最少的知识,而其局限于那些与本单位密切相关的软件单位. 迪米特法则的目的在于降低类之间的耦合.由于每个类尽量减少对其他类的依赖,因此,很容易使得系统的功能模块相互独立,相互之间不存在依赖关系.应用迪米特

设计模式六大原则之五:迪米特法则

定义:一个对象应该对其他对象保持最少的了解. 问题由来:类与类之间的关系越密切,耦合度越大,当一个类发生改变时,对另一个类的影响也越大. 解决方案:尽量降低类与类之间的耦合. 自从我们接触编程开始,就知道了软件编程的总的原则:低耦合,高内聚.无论是面向过程编程还是面向对象编程,只有使各个模块之间的耦合尽量的低,才能提高代码的复用率.低耦合的优点不言而喻,但是怎么样编程才能做到低耦合呢?那正是迪米特法则要去完成的. 迪米特法则又叫最少知道原则,最早是在1987年由美国Northeastern Un

2015-03-10--模板方法模式,迪米特法则

今天上午有事,下午回来先休息了一下,后来开始学习.今天先看的其实是STL的vector,不是简单的看啊,用谁不会,要自己亲自动手实践一个,不过到现在了还没有实现,明天自己再做一个vector吧,今天主要是看了别人的代码了,并且分析了一下,其实有时候分析和设计的环节要是比真正编写代码还重要啊. 后来晚上继续我们的设计模式,今天仍然是看的比较少,看了模板方法模式和迪米特法则.我们一个一个的收,先说模板方法模式. 上图: 模板方法模式是通过把不变行为搬移到超类,去除子类中的重复代码来体现它的优势. 其

设计模式之6大原则(5)-迪米特法则

迪米特法则(Law of Demeter)又叫作最少知识原则(Least Knowledge Principle 简写LKP),就是说一个对象应当对其他对象有尽可能少的了解,不和陌生人说话.英文简写为: LoD. 迪米特法则可以简单说成:talk only to your immediate friends. 对于面向OOD来说,又被解释为下面几种方式:一个软件实体应当尽可能少的与其他实体发生相互作用.每一个软件单位对其他的单位都只有最少的知识,而且局限于那些与本单位密切相关的软件单位. 迪米特

设计模式六大原则(5):迪米特法则

迪米特法则 定义:一个对象应该对其他对象保持最少的了解. 问题由来:类与类之间的关系越密切,耦合度越大,当一个类发生改变时,对另一个类的影响也越大. 解决方案:尽量降低类与类之间的耦合. 迪米特法则(Law of  Demeter, LoD):一个软件实体应当尽可能少地与其他实体发生相互作用. 如果一个系统符合迪米特法则,那么当其中某一个模块发生修改时,就会尽量少地影响其他模块,扩展会相对容易,这是对软件实体之间通信的限制,迪米特法则要求限制软件实体之间通信的宽度和深度.迪米特法则可降低系统的耦

GoF之迪米特法则

猫拿着手枪对着老鼠说:1+1等于几?.老鼠战战兢兢的回答:等..等于2.啪-,老鼠被打死了,猫酷酷的吹着枪管说:怪只怪你知道的太多了. 我们就在这个小故事里认识最后一个原则吧. 迪米特法则(Law Of Demeter) 定义1:如果两个类不用直接通信,那么这两个类就不应当发生直接的相互作用,如果一类需要调用另一个类的某一个方法的话,需要第三方转发这个调用. 定义2:在类的结构设计上,尽量降低成员的访问权限. 优点: 迪米特法则其根本思想,是强调了类之间的松耦合,类之间的耦合越弱,越有利于复用,

设计模式六大原则——迪米特法则(LoD)

1.背景 在图书馆借书,刚开始的时候,直接跑到相应的楼层去,到里面去转,去找要借的书,在里面溜达半天才能找到:后来知道图书馆有一个电脑查询处,然后直接在电脑上输入想要借的书,电脑就会显示你想要借的书的信息,还有所在的相关楼层存放的相关位置. 2.定义 迪米特法则(Law of Demeter)又叫作最少知识原则(LKP,Least Knowledge Principle),就是说一个对象应当对其他对象有尽可能少的了解,类与类之间的了解的越多,关系越密切,耦合度越大,当一个类发生改变时,另一个类也

六大设计原则之迪米特法则

定义:一个类和另一个类应该保持最小的了解 问题由来:类与类之间的关系越密切,耦合度越大,当一个类发生变化时,对另一个类影响也越大. 解决方案:尽量降低类与类之间的耦合. //总公司员工 class Employee{ private String id; public void setId(String id){ this.id = id; } public String getId(){ return id; } } //分公司员工 class SubEmployee{ private Str

七大设计原则之迪米特法则

定义 迪米特法则(Law of Demeter,LoD)也称为最少知识原则(Least Knowledge Principle,LKP). 一个对象应该对其他对象有最少的了解.通俗地讲,一个类应该对自己需要耦合或调用的类知道得最少,它的内部是如何复杂都和自己没关系,只需知道它提供的public方法,其他的一概不关心. 广义的迪米特法则:    一个模块设计的好坏的一个重要标志就是该模块在多大程度上讲自己的内部数据与实现的有关细节隐藏起来.    一个软件实体应当尽可能少的与其他实体发生相互作用.