定义：一个对象应当对其他对象有尽可能少的了解,只和朋友说话，不和陌生人说话
朋友的介定：
1、自身This（不用解释）
2、方法参数传入
public void drive(Car car) {
car.move();
}
3、成员变量；
4、成员变量的集合
private List<Car> cars ;
类中的Car也是朋友
5、创建出来的对象；
public class CarFactory {
public Car createCar() {
return new Car();
}
}
此处类中的Car也为朋友；只要不在这5种这类的都是陌生人；那么此类尽量不要和陌生人交流（有可能陌生人是人犯子哦）；
举例说明：
在现实生活中我们也经常遇到这样的情况。比如你想办一件事情，但是凭借你的能力是做不到的，而你周围的朋友也无法帮你办到。但是恰好你有一个朋友认识有另外一个朋友可以办得成此事，那么你只有拜托你这位朋友中间牵线搭桥，让他的朋友帮你办好此事。
在这个例子中，我们就暂且定义你为A，你的朋友为B，你朋友的朋友为C好了。
我们先来看看表达此种关系的UML类图：
实现代码如下：
1.类A和类B是好朋友，能找到类B来帮忙：
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(); } }2.类B和类C是好朋友，能知道类C来帮忙：
public classB{ private String name; publicB(String name){ this.name = name; } publicCgetC(String name){ return new C(name); } }3.类C能够办成此事：
public classC{ public String name; publicC(String name){ this.name = name; } publicvoidwork(){ System.out.println(name + "把这件事做好了"); } }4.场景类
public classClient{ publicstaticvoidmain(String[] args){ A a = new A("张三"); a.work(); } }运行结果如下：
王五把这件事做好了上面的输出虽然是把事情成功办好了，但是仔细看业务逻辑明显是不对的。A和C又不是好朋友，为什么在类A中会出现类C呢？他们又互相不认识。
看到这里很多人都会明白，这种场景在实际开发中是非常常见的一种情况。对象A需要调用对象B的方法，对象B有需要调用对象C的方法……就是常见的getXXX().getXXX().getXXX()……类似于这种代码。如果你发现你的代码中也有这样的代码，那就考虑下是不是违反迪米特法则，是不是要重构一下了。
为了符合迪米特法则，也为了让业务逻辑能够说得通，我们把上面的例子稍微修改一下。
UML类图如下：
代码如下：
1.类A和类B是好朋友，能找到类B来帮忙：
public classA{ public String name; publicA(String name){ this.name = name; } publicBgetB(String name){ return new B(name); } publicvoidwork(){ B b = getB("李四"); b.work(); } }2.类B和类C是好朋友，能知道类C来帮忙：
public classB{ private String name; publicB(String name){ this.name = name; } publicCgetC(String name){ return new C(name); } publicvoidwork(){ C c = getC("王五"); c.work(); } }3.类C能够办成此事：
public classC{ public String name; publicC(String name){ this.name = name; } publicvoidwork(){ System.out.println(name + "把这件事做好了"); } }4.场景类
public classClient{ publicstaticvoidmain(String[] args){ A a = new A("张三"); a.work(); } }运行结果如下：
王五把这件事做好了上面代码只是修改了下类A和B的work方法，使之符合了迪米特法则：
类A只与最直接的朋友类B通信，不与类C通信； 类A只调用类B提供的方法即可，不用关心类B内部是如何实现的（至于B是怎么调用的C，这些A都不用关心）。最后总结：记住朋友法则；
优点：系统 耦合度低；
缺点：产生太多的中间类；系统复杂。
