您的位置:首页 > 其它

设计模式之迪米特原则(LOD)(最少知识原则)

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

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

概念:

LOD:LOD,Law Of Demeter

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

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

如果两个类不必彼此直接通信,那么这两个类就不应当发生直接的相互作用。

如果其中的一个类需要调用另一个类的某一个方法的话,可以通过第三者转发这个调用。

我们更为形象的来这样说:

“某人”与一个“朋友”组成自己的朋友圈,两个人都需要与一个圈外的“陌生人”发生相互作用。

“朋友” 与“陌生人”若是朋友,组成“朋友”的朋友圈。

“某人”并不需要与“陌生人”直接发生相互作用,而是通过“朋友”与之发生直接相互作用。

“朋友”实际起到了将“某人”对“陌生人”的调用转发给“陌生人”的作用。

可见,通过调用转发,隐藏了“陌生人”的存在,使得“某人”认为他所调用的方法是“朋友”的方法。

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

当前对象本身(this)

以参量形式传入到当前对象方法中的对象

当前对象的实例变量直接引用的对象

当前对象的实例变量如果是一个聚集,那么聚集中的元素也都是朋友

当前对象所创建的对象。

任何一个对象,如果满足上述条件之一,就是当前对象的“朋友”;否则就是“陌生人”。

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

遵循类之间的迪米特法则会使一个系统的局部设计简化,因为每个局部都不会与远距离的对象有直接的关联;但也会造成不同模块之间的通信效率降低,会使系统的不同模块之间不容易协调。

在系统中造出大量的小方法,散落在系统的各个角落。这些方法仅传递间接的调用,与系统的商务逻辑无关。

当设计师试图从一张类图中看出总体的架构时,这些小方法会造成迷惑和困扰。

改进办法:与依赖倒置原则互补使用

引入一个抽象的类型引用“抽象陌生人”对象,使“某人”依赖于“抽象陌生人”,亦即将“抽象陌生人”变成“朋友”。

只要新的具体的“陌生人”具有相同的抽象类型,那么某人就无法区分它们,从而允许“陌生人”的具体实现可独立于“某人”而变化。

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

(1) 在类的划分上,应该创建有弱耦合的类;

(2)在类的结构设计上,每一个类都应当尽量降低成员的访问权限;

(3)在类的设计上,只要有可能,一个类应当设计成不变类;

(4)在对其他类的引用上,一个对象对其它对象的引用应当降到最低;

(5)尽量降低类的访问权限;

(6)谨慎使用序列化功能;

(7)不要暴露类成员,而应该提供相应的访问器(属性)。

相应设计模式:
Façade
Mediator

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

SRP是基本
OCP是目的
DIP为手段
LSP是继承复用的基础
ISP是实现LoD的手段之一
CARP是复用的原则
多个原则应综合运用,共同达到目的----设计一个好的系统:可扩展性、灵活性、可插入性。
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: