六大设计原则详解(5)-迪米特法则

Android学习资源分享合集(1)-视频资源

简介:

迪米特法则（Law of Demeter）又叫作最少知道原则（Least Knowledge Principle 简写LKP），就是说一个对象应当对其他对象有尽可能少的了解,不和陌生人说话。英文简写为: LoD.
迪米特法则的初衷在于降低类之间的耦合。由于每个类尽量减少对其他类的依赖，因此，很容易使得系统的功能模块功能独立，相互之间不存在（或很少有）依赖关系。

---

下面通过几个方面来解析迪米特法则，示例借鉴了<设计模式之禅>

一.Only talk to your immediate friends

Only talk to your immediate friends(只与直接的朋友通信)，每个对象都必然会与其他对象有耦合关系，两个对象之间的耦合就成为朋友关系，这种关系的类型有很多，如组合、聚合、依赖等。下面通过例子来了解这句话的含义。

有这么一个场景，体育老师想让体育委员来确认一下女生是否来齐，下面建立一个Teacher类，并写个commond方法来发送命令给体育委员，代码如下:

public class Teacher {    public void commond(GroupLeader groupLeader) {        List<Girl> listGirls = new ArrayList<Girl>();        for (int i = 0; i < 20; i++) {            listGirls.add(new Girl());        }        groupLeader.countGirls(listGirls);    }}

体育委员的GroupLeader的实现类如下:

public class GroupLeader { //查女生的数量    public void countGirls() {        System.out.println(女生数量是： + listGirls.size());    }}

从场景中我们得知体育委员和老师都和女生类产生依赖，所以定义一个女生类(空类)如下:

public class  Girl{}

下面是场景的实现：

public class  Client{  public  static void main (String[ ] args ){Teacher teacher=new Teacher();//发命令teacher.commond(new GroupLeader());}}

运行的结果是女生的数量是：20人
分析之前先要确定一下什么是朋友类，朋友类的定义：出现在成员变量、方法的输入输出参数中的类。 而方法体类内部的类不能算。
在Teacher类中最直观的朋友类是GroupLeader，那Girl类是不是朋友类呢？根据迪米特法则中对朋友类的定义，方法体类内部不是朋友类，我们知道Girl类不是朋友类，因为他包含在commond方法内。Teacher类与陌生的类发生了交流，违背了迪米特法则。

正确的Teacher类，GroupLeader类，Client类如下：

public class Teacher {    public void commond(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(String[ ] args){List<Girl> listGirls =new ArrayList<Girl>();for(int i=0;i<20;i++){listGirls.add(new Girl());}Teacher teacher=new Teacher();teacher.commond(new GroupLeader(listGirls))}}

---

二.不能过于亲密

迪米特法则规定只与直接的朋友通信，但是不能过于亲密，否则耦合关系变得异常牢固，而且，修改时涉及的面也就越大，变更引起的风险就越大。因此，要适时反复衡量：是否可以减少public方法和属性，改为private、package－private、protected等访问权限，及是否可以加上final关键字。

---

三.是自己的就是自己的

如果我们发现在一个类中的一个方法，放在本类可以，放在其他的类中也可以并且对任何的类都不产生影响，那么就遵循一个原则，把方法放在本类中。

---

总结:

1.只与直接的朋友通信。
2.不能过于亲密。
3.自己的就是自己的。
4.谨慎使用Serializable。

我的公众号如下，希望大家多多支持：