软件设计原则----迪米特法则(LoD)

“一个对象应该对其他对象有尽可能少的了解”

“Only talk to your  immediate friends”

“Don’t talk to strangers”

“每一个软件单位对其他的单位都只有最少的知识,而且局限于那些与本单位密切相关的软件单位”

  ……

来源:
迪米特法则(LoD)最初是用来作为面向对象的系统设计风格的一种法则,是很多著名系统,如火星登陆软件系统、木星的欧罗巴卫星轨道飞船的软件系统的指导设计原则。

迪米特法则(LoD)又可分为两种:狭义的迪米特法则(LoD)和广义的迪米特法则(LoD)。

狭义的迪米特法则(LoD):

  • 如果两个类不必彼此直接通信,那么这两个类就不应当发生直接的相互作用。
  • 如果其中的一个类需要调用另一个类的某一个方法的话,可以通过第三者转发这个调用。
我们更为形象的来这样说:
  • “某人”与一个“朋友”组成自己的朋友圈,两个人都需要与一个圈外的“陌生人”发生相互作用。
  • “朋友” 与“陌生人”若是朋友,组成“朋友”的朋友圈。
  • “某人”并不需要与“陌生人”直接发生相互作用,而是通过“朋友”与之发生直接相互作用。
  • “朋友”实际起到了将“某人”对“陌生人”的调用转发给“陌生人”的作用。
可见,通过调用转发,隐藏了“陌生人”的存在,使得“某人”认为他所调用的方法是“朋友”的方法。

关键在于朋友圈的确定。 “朋友”的条件:

  • 当前对象本身(this)
  • 以参量形式传入到当前对象方法中的对象
  • 当前对象的实例变量直接引用的对象
  • 当前对象的实例变量如果是一个聚集,那么聚集中的元素也都是朋友
  • 当前对象所创建的对象。
任何一个对象,如果满足上述条件之一,就是当前对象的“朋友”;否则就是“陌生人”。

狭义的迪米特法则(LoD)的缺点:

  1. 遵循类之间的迪米特法则会使一个系统的局部设计简化,因为每个局部都不会与远距离的对象有直接的关联;但也会造成不同模块之间的通信效率降低,会使系统的不同模块之间不容易协调。
  2. 在系统中造出大量的小方法,散落在系统的各个角落。这些方法仅传递间接的调用,与系统的商务逻辑无关。
  3. 当设计师试图从一张类图中看出总体的架构时,这些小方法会造成迷惑和困扰。
改进办法:与依赖倒置原则互补使用
  • 引入一个抽象的类型引用“抽象陌生人”对象,使“某人”依赖于“抽象陌生人”,亦即将“抽象陌生人”变成“朋友”。
  • 只要新的具体的“陌生人”具有相同的抽象类型,那么某人就无法区分它们,从而允许“陌生人”的具体实现可独立于“某人”而变化。
广义的迪米特法则(LoD):
  1. 对对象之间的信息流量、流向以及信息的影响进行控制。
  2. 充分体现封装的概念。
  3. 具体应用时,需注意:
  • 类的划分上,创建弱耦合的类;
  • 类的结构设计上,每个类应降低成员的访问权限;
  • 类的设计上,只要有可能,设计成不变类;
  • 对其他类的引用上,对其他对象的引用应该降到最低。

相应设计模式:
Façade
Mediator


设计原则间的关系:
在这一系列的文章中,我们介绍了几种设计原则,在这最后一个原则中,小结一下他们之间的关系:

SRP是基本
OCP是目的
DIP为手段
LSP是继承复用的基础
ISP是实现LoD的手段之一
CARP是复用的原则 
 多个原则应综合运用,共同达到目的----设计一个好的系统:可扩展性、灵活性、可插入性。

参考资源:

《设计模式:可复用面向对象软件的基础》,ERICH GAMMA RICHARD HELM RALPH JOHNSON JOHN VLISSIDES著作,李英军 马晓星 蔡敏 刘建中译,机械工业出版社,2005.6

《敏捷软件开发:原则、模式与实践》,Robert C. Martin著,邓辉译,清华大学出版社,2003.9

《设计模式解析》,Alan Shalloway等著(徐言声译),人民邮电出版社,2006.10


你可能感兴趣的:(软件架构)