设计模式六大原则 - 迪米特法则

   <p>迪米特法则有很多种说法，比如：一个类应该应该对其他类尽可能了解得最少；类只与直接的朋友通信等等。但是其最终目的只有一个，就是让类间解耦。</p>    <h2>定义</h2>    <p>迪米特法则：Law Of Demeter，LoD。</p>    <p>也被称为最少知识原则，Least Knowledge Principle，LKP。</p>    <p>就是说一个对象应该对其他对象保持最少的了解。正如最少知识原则这个定义一样，一个类应该对其耦合的其他类或所调用的类知道得最少。所耦合的类内部无论如何复杂，怎么实现的我都不需要知道，我只调用你public出来的这些方法，其他都不用知道。</p>    <p>另外可以解释一下开头提到的只与直接的朋友通信，什么叫直接的朋友呢？我们继续看。</p>    <h2>举个例子</h2>    <p>光看定义可能无法完全理解它所表达的含义，以及在什么场景下才需要使用这个迪米特法则。现在我们就来举个“栗子”。</p>    <p>现在市面上各种人脉书上很多都会提到“六度人脉”这个理论，这个理论说的是你与世界上任何一个人中间只隔了六个人。也就是说你想找任何一个人，无论这个人是政界要人，还是商界巨鳄，抑或是明星名人，你最多只通过六个人就可以联系到他（想想还有点小激动呢-_-#）。</p>    <p>我们暂且不论这个理论是对是错，在现实生活中我们也经常遇到这样的情况。比如你想办一件事情，但是凭借你的能力是做不到的，而你周围的朋友也无法帮你办到。但是恰好你有一个朋友认识有另外一个朋友可以办得成此事，那么你只有拜托你这位朋友中间牵线搭桥，让他的朋友帮你办好此事。</p>    <p>在这个例子中，我们就暂且定义你为A，你的朋友为B，你朋友的朋友为C好了。</p>    <h2>反面教材</h2>    <p>我们先来看看表达此种关系的UML类图：</p>    <p style="text-align:center"><img src="https://simg.open-open.com/show/89c6890ddc0a4a911a203ce151f45e15.png"></p>    <p>实现代码如下：</p>    <p>1.类A和类B是好朋友，能找到类B来帮忙：</p>    <pre>  <code class="language-java">public classA{     public String name;     publicA(String name){    this.name = name;   }     publicBgetB(String name){    return new B(name);   }     publicvoidwork(){    B b = getB("李四");    C c = b.getC("王五");    c.work();   }  }  </code></pre>    <p>2.类B和类C是好朋友，能知道类C来帮忙：</p>    <pre>  <code class="language-java">public classB{     private String name;     publicB(String name){    this.name = name;   }     publicCgetC(String name){    return new C(name);   }  }  </code></pre>    <p>3.类C能够办成此事：</p>    <pre>  <code class="language-java">public classC{     public String name;     publicC(String name){    this.name = name;   }     publicvoidwork(){    System.out.println(name + "把这件事做好了");   }  }  </code></pre>    <p>4.场景类</p>    <pre>  <code class="language-java">public classClient{   publicstaticvoidmain(String[] args){    A a = new A("张三");    a.work();   }  }  </code></pre>    <p>运行结果如下：</p>    <pre>  <code class="language-java">王五把这件事做好了  </code></pre>    <p>上面的输出虽然是把事情成功办好了，但是仔细看业务逻辑明显是不对的。A和C又不是好朋友，为什么在类A中会出现类C呢？他们又互相不认识。</p>    <p>看到这里很多人都会明白，这种场景在实际开发中是非常常见的一种情况。对象A需要调用对象B的方法，对象B有需要调用对象C的方法……就是常见的getXXX().getXXX().getXXX()……类似于这种代码。如果你发现你的代码中也有这样的代码，那就考虑下是不是违反迪米特法则，是不是要重构一下了。</p>    <h2>正确例子</h2>    <p>为了符合迪米特法则，也为了让业务逻辑能够说得通，我们把上面的例子稍微修改一下。</p>    <p>UML类图如下：</p>    <p style="text-align:center"><img src="https://simg.open-open.com/show/d714b824345862c5f672fde5abccd761.png"></p>    <p>代码如下：</p>    <p>1.类A和类B是好朋友，能找到类B来帮忙：</p>    <pre>  <code class="language-java">public classA{     public String name;     publicA(String name){    this.name = name;   }     publicBgetB(String name){    return new B(name);   }     publicvoidwork(){    B b = getB("李四");    b.work();   }  }  </code></pre>    <p>2.类B和类C是好朋友，能知道类C来帮忙：</p>    <pre>  <code class="language-java">public classB{     private String name;     publicB(String name){    this.name = name;   }     publicCgetC(String name){    return new C(name);   }      publicvoidwork(){    C c = getC("王五");    c.work();   }  }  </code></pre>    <p>3.类C能够办成此事：</p>    <pre>  <code class="language-java">public classC{     public String name;     publicC(String name){    this.name = name;   }     publicvoidwork(){    System.out.println(name + "把这件事做好了");   }  }  </code></pre>    <p>4.场景类</p>    <pre>  <code class="language-java">public classClient{   publicstaticvoidmain(String[] args){    A a = new A("张三");    a.work();   }  }  </code></pre>    <p>运行结果如下：</p>    <pre>  <code class="language-java">王五把这件事做好了  </code></pre>    <p>上面代码只是修改了下类A和B的work方法，使之符合了迪米特法则：</p>    <ul>     <li>类A只与最直接的朋友类B通信，不与类C通信；</li>     <li>类A只调用类B提供的方法即可，不用关心类B内部是如何实现的（至于B是怎么调用的C，这些A都不用关心）。</li>    </ul>    <h2>总结</h2>    <p>迪米特法则的目的是让类之间解耦，降低耦合度。只有这样，类的可复用性才能提高。</p>    <p>但是迪米特法则也有弊端，它会产生大量的中转类或跳转类，导致系统的复杂度提高。</p>    <p>所以我们不要太死板的遵守这个迪米特法则，在系统设计的时候，在弱耦合和结构清晰之间反复权衡。尽量保证系统结构清晰，又能做到低耦合。</p>    <p> </p>    <p> </p>    <p>来自：https://tianweili.github.io/2015/02/12/设计模式六大原则-迪米特法则/</p>    <p> </p>