迪米特法则

迪米特法则
迪米特法则可以简单说成：talk only to your immediate friends。 对于面向OOD来说，又被解释为下面几种方式：
        一个软件实体应当尽可能少的与其他实体发生相互作用。每一个软件单位对其他的单位都只有最少的知识，而且局限于那些与本单位密切相关的软件单位。
　　 迪米特法则的初衷在于降低类之间的耦合。由于每个类尽量减少对其他类的依赖，因此，很容易使得系统的功能模块功能独立，相互之间不存在（或很少有）依赖关系。
　　迪米特法则不希望类直接建立直接的接触。如果真的有需要建立联系，也希望能通过它的友元类来转达。因此， 应用迪米特法则有可能造成的一个后果就是：
        系统中存在大量的中介类，这些类之所以存在完全是为了传递类之间的相互调用关系——这在一定程度上增加了系统的复杂度。
狭义的迪米特法则的缺点：
　　在系统里造出大量的小方法，这些方法仅仅是传递间接的调用，与系统的商务逻辑无关。
　　遵循类之间的迪米特法则会是一个系统的局部设计简化，因为每一个局部都不会和远距离的对象有直接的关联。但是，这也会造成系统的不同模块之间的通信效率降低，也会使系统的不同模块之间不容易协调。
　　门面模式和调停者模式实际上就是迪米特法则的应用。
广义的迪米特法则
       其实， 迪米特法则所谈论的，就是对对象之间的信息流量、流向以及信息的影响的控制。
       在软件系统中，一个模块设计得好不好的最主要、最重要的标志，就是该模块在多大的程度上将自己的内部数据和其它与实现有关的细节隐藏起来。一个设计得好的模块可以将它所有的实现细节隐藏起来；彻底地将提供给外界的API和自己的实现分隔开来。这样一来， 模块与模块之间就可以仅仅通过彼此的API相互通讯，而不理会模块内部的工作细节。这一概念就是“信息的隐藏”，或者叫做“封装”；也就是大家熟悉的软件设计的基本教义之一。
       信息的隐藏非常重要的原因在于，它可以使各个子系统之间脱耦；从而允许它们能够独立地被开发、优化、使用、阅读以及修改[BLOCH01]。这种脱耦化可以有效地加快系统的开发过程，因为可以独立地同时开发各个模块；它可以使维护过程变得容易，因为所有的模块都容易读懂，特别是不必担心对其它模块的影响。
        虽然信息的隐藏本身并不能带来更好的性能，但是它可以使性能的有效调整变得容易。一旦确认某一个模块是性能的障碍时， 设计人员可以针对这个模块本身进行优化，而不必担心影响到其它的模块。
      信息的隐藏可以促进软件的复用。由于每一个模块都不依赖于其它模块而存在，因此每一个模块都可以独立地在其它的地方使用。一个系统的规模越大，信息的隐藏就越是重要；而信息隐藏的威力也就越明显。