必威体育Betway必威体育官网
当前位置:首页 > IT技术

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

时间:2019-09-04 18:10:00来源:IT技术作者:seo实验室小编阅读:70次「手机版」
 

迪米特原则

这里写图片描述

迪米特原则的定义

迪米特原则(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个原则

管理是一种艺术,没有绝对的答案。管理风格是一种选择,选择会因人而异。那管理者在遇到问题,应该如何去解决呢?01每当遇到问题时,身为管

人机工程学的基本设计原则

1.极限设计原则(以某种人体尺寸极限作为设计参数的原则) 设计的最大尺寸参考选择人体尺寸的高百分位 设计的最小尺寸参考选择人体尺

ixdc国际体验设计大会2017六大参会价值!

全球极具影响力的体验设计大会专业&middot;权威&middot;盛大数以万计的设计领袖、商业领袖、产品运营者们正在这里分享案例,沟通交

数据可视化设计(2): 可视化设计原则

在上一篇文章《数据可视化设计(1) :情感化设计指导可视化设计理念》中,根据情感化设计本能、行为、反思三种水平,提出了清晰&炫酷、内

深度解析3条设计心理学原则,提升设计方案说服力

本篇文章为大家介绍了三条具有普适性意义的心理学原则:库克定律、米勒定律、雅各布定律,并分别介绍了其在设计领域中的应用。设计师

分享到:

栏目导航

推荐阅读

热门阅读