最少知识原则

　　该原则也叫作迪米特法则，还是这个名字高大上。。。

　　通俗的来讲，就是一个类对自己依赖的类知道的越少越好。也就是说，对于被依赖的类来说，无论逻辑多么复杂，都尽量地的将逻辑封装在类的内部，对外除了提供的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() {}
}