迪米特法则

参考链接：
http://blog.csdn.net/plusir/article/details/1104095
http://blog.csdn.net/brookes/article/details/1899680

迪米特法则，又叫最少知识原则，就是说，一个对象应当对其他对象有尽可能少的了解。

迪米特法则的各种表述(定义)
① 只与你直接的朋友们通信；
② 不要跟“陌生人”说话；
③ 每一个软件单位对其他的单位都只有最少的知识，而且局限于那些与本单位密切相关的软件单位。

这里所说的朋友，相对于具体某个类而言就是：成员对象，向方法传递的参数，这些都可以进行直接通信。狭义的迪米特法则是要求朋友提供调用的方法而无需与“陌生人”打交道。

优点：
<1>迪米特法则的初衷在于降低类之间的耦合。由于每个类尽量减少对其他类的依赖，因此，很容易使得系统的功能模块功能独立，相互之间不存在（或很少有）依赖关系。
<2>遵循迪米特法则会使一个系统的局部设计简化，因为每一个局部都不会和远距离的对象有直接关联

缺点：
<1>会在系统里造出大量的小方法，散落在系统的各个角落。这些方法仅仅是传递间接的调用，因此与系统的商务逻辑无关，当设计师试图从一张类图看出总体的框架时，这些小的方法会造成迷惑和困扰。
<2>会造成系统的不同模块之间的通信效率降低，也会使系统的不同模块之间不容易协调。

设计模式中的应用：
<1>门面模式(Facade Pattern)
<2>中介模式(Mediator Pattern)

在实际应用中，个人总结出来的经验，如果跨系统的接口访问，应该第一时间考虑参考这两种模式。要不然调用的代码会散落四周，导致强耦合，实际经验：UAP与PDMS系统整合时出现的问题。应该在PDMS中通过中介调用UAP的接口。PDMS的类对UAP中的接口应该是陌生的，但却与该陌生人打得太多交道，自己写的时候都觉得很生硬

在将迪米特法则运用到系统的设计中时，应注意的几点：
① 在类的划分上，应该创建有弱耦合的类；
② 在类的结构设计上，每一个类都应当尽量降低成员的访问权限；
③ 在类的设计上，只要有可能，一个类应当设计成不变类；
④ 在对其他类的引用上，一个对象对其它对象的引用应当降到最低；
⑤ 尽量降低类的访问权限；
⑥ 谨慎使用序列化功能；
⑦ 不要暴露类成员，而应该提供相应的访问器(属性)。