设计模式六大原则例子（五）-- 最少知识原则（LKP）/ 迪米特法则（LOD）例子

之前我们对设计模式的六大原则做了简单归纳，这篇博客是对最少知识原则进行的举例说明。

最少知识原则的意义

朋友类的定义：出现在成员变量、方法的输入输出参数中的类。而方法体类内部的类不能算。
每个对象都必然会与其他对象有耦合关系，两个对象之间的耦合就成为朋友关系，这种关系的类型有很多，如组合、聚合、依赖等。

具体实现：

在实际应用中经常会出现这样一个方法：放在本类中也可以，放在其他类中也没有问题，怎么去衡量呢？建议：如果一个类放在本类中，既不增加类间关系，又不对本类产生不负面影响，就放置在本类中。

• 在类的划分上，应该创建有弱耦合的类
• 在类的结构设计上，每一个类都应当尽量降低成员的访问权限
• 在类的设计上，只要有可能，一个类应当设计成不变类，防止类的行为被篡改
• 在对其他类的引用上，一个对象对其它对象的引用应当降到最低
• 尽量降低类的访问权限
• 不要暴露类成员，而应该提供相应的访问器(属性),

最少知识原则的优点

• 类负责的职责清晰明了，使类可以高度内聚降低类与类之间的耦合

最少知识原则的例子

1.不符LKP的反例：
体育老老师让体委清点全班女生个数。类图如下：：

源代码如下：

看看上面的要求：老师 让 组长 清点 女生 数目。老师与女生是陌生关系啊（老师不需要女生执行任何动作）。显然，上述做法违背LoD法则。
依据LKP法则解耦（与真实意义上的陌生类解耦，这里而不应为上述类图中未正确体会语义的虚假朋友类Girl），设计图如下：

新的代码如下：

2.朋友间不要过于亲密，太亲密则过于耦合。（根据情况，缩减访问控制域）
我们举一个厨师跟买菜助手的关系，设计图如下：

代码如下：

运行结果：

程序虽然没有错，但是厨师过多的干预到购买员的工作了，效率低下，以后维护起来可不简单。耦合关系变得异常牢固，谁都离不开谁了，要是厨师离职，新的厨师要重新学习新的购买流程才能获取到食材，要是购买员离职，新来的购买员需要重新学习按照厨师的采购顺序才能正确的拿到食材，这也是不正常的。

改为如下：

代码如下：

运行结果如下：