六大设计原则之迪米特原则
2016-08-27 16:05
645 查看
迪米特原则的定义
迪米特原则(Law of Demeter,LoD),也叫最少知识原则(Low knowledge Principle,LKP):一个对象应该对其他对象有最少的了解。
通俗的讲:一个类对自己需要耦合或调用的类知道的最少,你(被耦合或调用的类)的内部是如何复杂和我没有关系,我就知道你提供的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的访问,降低了系统间的耦合,提高了系统的健壮性。
朋友类间也是要有距离
我们在安装软件时,经常会有一个安装向导的过程。比如第一步确认是否安装,第二步确认License,第三步选择安装目录…..。这个是一个典型的顺序执行动作,我们定义软件安装过程的类图如下:导向类:
public class Wizard{ private Random rand = new Random(System.currentTimeMillis()); //第一步 public int first(){ System.out.println("执行第一个方法....."); return rand.nextInt(100); } //第二步 public int second(){ System.out.println("执行第二个方法....."); return rand.nextInt(100); } //第三步 public int third(){ System.out.println("执行第三个方法....."); return rand.nextInt(100); } }
InstallSoftware类:
public class InstallSoftware{ public void installWizard(Wizard wizard){ int first = wizard.first(); //根据first返回的结果,看是否要执行下一步 if(first >50){ int second = wizard.second(); if(second >50){ wizard.third(); } } } }
场景类:
public class Client{ public static void main(Strings[] args){ InstallSoftware invoker = new InstallSoftware(); invoker.installWizard(new Wizard()); } }
以上的程序非常简单,但是隐藏了一个问题。Wizard类把太多的方法暴露给InstallSoftware类,导致两者的关系太亲密,耦合关系变量异常牢固。我们把Wizard类进行重构,uml类图如下:
修改后的Wizard类:
public class Wizard{ private Random rand = new Random(System.currentTimeMillis()); //第一步 private int first(){ System.out.println("执行第一个方法....."); return rand.nextInt(100); } //第二步 private int second(){ System.out.println("执行第二个方法....."); return rand.nextInt(100); } //第三步 private int third(){ System.out.println("执行第三个方法....."); return rand.nextInt(100); } //软件安装过程 public void installWizard(){ int first = wizard.first(); //根据first返回的结果,看是否要执行下一步 if(first >50){ int second = wizard.second(); if(second >50){ wizard.third(); } } } }
修改后的InstallSoftware类:
public class InstallSoftware{ public void installWizard(Wizard wizard){ wizard.installWizard() } }
通过重构,类间的耦合关系变弱了,结构变得清晰,变量的风险也变小了。
一个类公开的public方法和属性越多,修改时涉及的面也就越大,变更引起的风险扩散也就越大。因此,为了保持朋友类间的距离,在设计时需要反复衡量:是否还可以再减少public方法和属性,是否可以修改为private,package-private,protected等访问权限,是否可以加上final关键字。
注意:
迪米特原则要求类“羞涩”一点,尽量不要对外公开太多的public方法和非静态的public变量,尽量内敛,多使用private,package-private,protected等访问权限。
是自己的就是自己的
在实践中经常出现这样一个方法,放在本类中也可以,放到其它类中也可以。那怎么处理呢?你可以坚持一个原则:如果一个方法放在本类中,即不增加类间关系,也对本类不产生负面影响,那就放到本类中。迪米特原则的实践
迪米特原则的核心观念就是类间解耦,弱耦合,只有弱耦合后,类的复用率才可以提高。其结果就是产生了大量的中转或跳转类,导致系统复杂,为维护带来了难度。所以,我们在实践时要反复权衡,即要让结构清晰,又做到高内聚低耦合。相关文章推荐
- 设计模式六大原则(5):迪米特原则
- 设计模式之禅——六大设计原则之迪米特原则
- 设计模式六大原则(5)-迪米特法则
- 设计模式 之 设计的 六大原则(5)迪米特法则
- 六大设计原则-迪米特原则【Low Of Demeter】
- 设计模式六大原则(5)——迪米特原则
- 设计模式六大原则5—迪米特原则
- 设计模式六大原则:迪米特原则-带你走进梦幻西游(四)
- 设计模式六大原则之----迪米特、开闭原则(六大原则简单总结)
- 设计模式六大原则(5):迪米特法则
- 设计模式六大原则(5):迪米特法原则
- 设计模式六大原则 - (5):迪米特法则
- 设计模式之禅之六大设计原则-迪米特原则
- [设计模式之禅读书笔记]005_设计模式六大原则(五):迪米特原则
- 设计模式六大原则--迪米特法制(LoD,LKP)
- 设计模式之六大原则——迪米特法则(LoD,LKP)
- 设计模式之六大原则——依赖倒置原则(DIP)
- 设计模式之六大原则——里氏替换原则(LSP)
- 设计模式——六大设计原则
- 设计模式之六大原则——开闭原则(OCP)