《HFDP》读书笔录（七）——最少知识

七、最少知识（Least Knowledge）原则

只和你的密友谈话。

另一个名称叫墨忒耳法则（Law of Demeter）。

1. 我们倾向于使用最少知识原则：

2. 这个名字更直接。

法则（law）给人的感觉是强制的。事实上，没有任何原则是法律（law），所有的原则都应该在有帮助的时候才遵守。所有的设计都不免需要折中（在抽象和速度之间取舍，在空间和时间之间平衡……）。虽然原则提供了方针，但在采用原则之前，必须全盘考虑所有的因素。

我感觉，这个原则更多的是属于类模式，因为类模式的关系才是在编译时决定的（同样，是否遵循这个原则，在编码后编译是已经决定了）。

这个原则希望我们在设计中，不要让太多的类耦合在一起，免得修改系统中一部分，会影响到其他部分。

那如何才能避免“赢得太多的朋友和影响太多的对象”？就是要遵循以下指导方针：

就任何对象而言，在该对象的方法内，我们只应该调用属于以下范围的方法：

• 该对象本身

• 被当作方法的参数而传递进来的对象

• 此方法所创建或实例化的任何对象

• 对象的任何组件

前三条方针告诉我们，如果某对象是调用其他的方法的返回结果，不要调用该对象的方法！

而第四条，则把“组件”想像成是被实例化变量所引用的任何对象，换句话说，把这想像成是“有一个”（Has-A）关系。

示例：

public House { WeatherStation station; // 其他的方法和构造器 public float getTemp () { return station.getThermometer ().getTemperature (); // 违反最少只是原则了，因为在此调用的方法属于另一个调用的返回对象。 } } public House { WeatherStation station; // 其他的方法和构造器 public float getTemp () { Thermometer thermometer = station.getThermometer (); return getTempHelper (thermometer); } public float getTempHelper ( Thermometer thermometer ) { return thermometer.getTemperature (); } // 没有违反最少知识原则，但是，把程序改成这样真的有意义吗？ } public House { WeatherStation station; // 其他的方法和构造器 public float getTemp () { return station.getTemperature (); // 应用此原则时，我们在气象站中加进一个方法，用来向温度计请求温度。 // 这可以减少我们所依赖的类的数目。 } }

和其他原则一样，我们都要按情形决定是否遵循原则。比如Java的System.out.print ();又如何？