该原则也叫作迪米特法则，还是这个名字高大上。。。
通俗的来讲，就是一个类对自己依赖的类知道的越少越好。也就是说，对于被依赖的类来说，无论逻辑多么复杂，都尽量地的将逻辑封装在类的内部，对外除了提供的public方法，不对外泄漏任何信息。该原则还有一个更简单的定义：只与直接的朋友通信。首先来解释一下什么是直接的朋友：每个对象都会与其他对象有耦合关系，只要两个对象之间有耦合关系，我们就说这两个对象之间是朋友关系。耦合的方式很多，依赖、关联、组合、聚合等。其中，我们称出现成员变量、方法参数、方法返回值中的类为直接的朋友，而出现在局部变量中的类则不是直接的朋友。也就是说，陌生的类最好不要作为局部变量的形式出现在类的内部。
当设计一个系统，不管他是什么对象，我们都需要注意他所交互的类有哪些，并注意这些类是如何交互的。该原则希望我们在设计中，不要让太多的类耦合在一起，免得修改系统中的一部分，会影响到其他部分。如果许多类之间相互依赖，那么这个系统就会变成一个易碎的系统，维护的成本也随之变得不可估量了。。。
如何遵守这个原则？
就任何对象而言，在该对象的方法内，应该调用（综合各种因素，尽量遵守）：
a. 该对象本身；
b. 被当做方法的参数而传递进来的对象；
c. 此方法所创建的或实例化的对象；
d. 对象的任何组件。。。
代码示例A：（未遵守原则）
public float GetTemp()
{
C c = D.GetC();
return c.GetTemperature();
}
代码示例B：（遵守原则）
public float GetTemp()
{
return D.GetTemperature();
}
对比代码示例A，B。代码示例A中，从对象D中取到对象C，再从对象C中获取温度值；而代码示例B中，直接从对象D中获取温度值，这样可以减少我们所依赖的对象的个数。
代码示例C：（较全面）
public class Car
{
// 下面注释对应上面的原则（a,b,c,d）
Engine engine; // d
public Car() {}
public void Start(Key key) // b
{
Doors doors = new Doors(); // c
boolean bIsOK = key.Turns(); // b
if(bIsOK)
{
engine.Start(); // d
UpdateDash(); // a
doors.Lock(); // c
}
}
public void UpdateDash() {}
}