软件设计模式之迪米特法则(Darren)

各位博友晚上好

先回顾一下之前学习的设计模式和原则

简单工厂模式，策略模式，单一职责原则，开放封闭原则，依赖倒转原则，装饰模式，代理模式，抽象工厂模式，原型模式（Copy，深复制，浅复制）以及昨天刚刚学习的模板方法（最大化优化代码）。

今天吃完饭听了一会猫扑 络电台，感觉里面的MM声音不错

迪米特法则定义（Law of Demeter）

又叫最少知识法则（Least Knowledge Principle 简写LKP），就是说一个对象应当对其它对象尽可能少的了解，不和陌生人说话。英文简写:LoD。

它在软件中的定义是这样的:如果两个类之间不必彼此直接进行通信，那么这两个类就不应该发生直接的相互作用。如果其中一个类需要用另一个类的方法的话，可以通过第三者来转发这个调用。

用我们现在的国情来举个例子，当今 会是个靠关系吃饭的 会，没有关系寸步难行啊，这也就是我们 会现在主要的弊病，官场腐败，行业内部都是尔虞我诈。为什么会这样呢，人们为了生存，都在找自己的关系 络，不管是高层底层通吃，这样的弊端是什么，关系复杂啊。还记得“蜗居”里面的一句台词：关系越用越活。这样 的后果就是人际关系复杂，尤其是负责公关的，这一点体现的尤为明显，当我我是一个最看不惯爱攀关系的人，

迪米特首先强调的是在类的设计上，每一个类都应该尽量降低类的访问权限，也就是说一个类包装好自己的private状态，不需要让别的类知道的字段和方法就不要公开。迪米特原则的根本思想是强调了类之间的松耦合。

类之间的耦合度越弱，越有利于被复用，一个处在弱耦合的类被修改，不会对关系的类造成波及。也就是说信息的隐藏促进了软件的复用。

1987年秋天由美国Northeastern University的Ian Holland提出，被UML的创始者之一Booch等普及。后来，因为在经典著作《 The Pragmatic Programmer》而广为人知。

模式和意义:

迪米特法则可以简单说成：talk only to your immediate friends。

对于面向OOD来说，又被解释为下面几种方式：一个软件实体应当尽可能少的与其他实体发生相互作用。每一个软件单位对其他的单位都只有最少的知识，而且局限于那些与本单位密切相关的软件单位。

迪米特法则的初衷在于降低类之间的耦合。由于每个类尽量减少对其他类的依赖，因此，很容易使得系统的功能模块功能独立，相互之间不存在（或很少有）依赖关系。

迪米特法则不希望类直接建立直接的接触。如果真的有需要建立联系，也希望能通过它的友元类来转达。因此，应用迪米特法则有可能造成的一个后果就是：系统中存在大量的中介类，这些类之所以存在完全是为了传递类之间的相互调用关系——这在一定程度上增加了系统的复杂度。

有兴趣可以研究一下设计模式的门面模式（Facade）和中介模式（Mediator），都是迪米特法则应用的例子。

值得一提的是，虽然Ian Holland对计算机科学的贡献也仅限于这一条法则，其他方面的建树不多，但是，这一法则却不仅仅局限于计算机领域，在其他领域也同样适用。比如，美国人就在航天系统的设计中采用这一法则。