设计模式-最少知识原则

当你正在设计一个系统，不管是任何对象，你都要注意它所交互的类有哪些，并注意它和这些类是如何交互的。

最少知识原则希望我们在设计中，不要让太多的类耦合在一起，以免修改系统中的一部分，会影响到其他部分。如果许多类之间相互依赖，那么这个系统就会变成一个易碎的系统，它需要花很多成本维护，也会因为太复杂而不容易被其他人了解。

下面看一句不太好的代码：（从气象站取得温度计对象，然后再从温度计对象去的温度）

public float getTemp(){
	return station.getThermometer().getTemperature();
}

依赖的类过多，究竟怎样才能避免这样呢？最少知识原则提供了一些方针：

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

1）该对象本身

2）被当做方法的参数而传递进来的对象

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

4）对象的任何组件

请注意！！！前3条的意思是，如果某对象是调用其他方法的返回结果，不要调用该对象的方法！第4条中的组件可以想象成被实例变量所引用的任何对象。

按着这些方针修改上面的代码：（减少当前类所依赖的数目）

public float getTemp(){
	return station.getTemperature();
}

这需要在气象站中加进一个方法，用来向温度计请求温度。

采用最少知识原则的优点：减少对象的依赖，这会减少软件的维护成本。

缺点：会导致更多的包装类被制造出来，用来处理和其他组件的沟通，这可能会导致复杂度和开发时间的增加，并降低运行时的性能。

所以，所有的原则都应该在有帮助的时候才遵守。所有的设计都不免需要折衷，即在抽象和速度之间取舍，在空间和时间之间平衡。

在采用原则之前，必须全盘考虑所有的因素。