【设计模式】迪米特法则

1 迪米特法则概述

迪米特法则来自于1987年美国东北大学(Northeastern University)一个名为“Demeter”的研究项 目。迪米特法则又称为最少知识原则(LeastKnowledge Principle, LKP),其定义如下:

迪米特法则:每一个软件单位对其他单位都只有最少的知识,而且局限于那些与本单位密切相关的软件单位。

迪米特法则要求一个软件实体应当尽可能少地与其他实体发生相互作 用。如果一个系统符合迪米特法则,那么当其中某一个模块发生修改时,就会尽量少地影响其他模块,扩展会相对容易,这是对软件实体之间通信的限制,迪米特法则要求限制软件实体之间通信的宽度和深度。迪米特法则可降低系统的耦合度,使类与类之间保持松散的耦合关系。

迪米特法则还有几种定义形式,包括:不要和“陌生人”说话、只与你的直接朋友通信等,在迪米特法则中,对于一个对象,其朋友包括以下几类:

  • 当前对象本身(this);
  • 以参数形式传入到当前对象方法中的对象;
  • 当前对象的成员对象;
  • 如果当前对象的成员对象是一个集合,那么集合中的元素也都是朋友;
  • 当前对象所创建的对象。

任何一个对象,如果满足上面的条件之一,就是当前对象的“朋友”,否则就是“陌生人”。在应用迪米特法则时,一个对象只能与直接朋友发生交互,不要与“陌生人”发生直接交互,这样做 可以降低系统的耦合度,一个对象的改变不会给太多其他对象带来影响

直接朋友指的是:类的成员变量,方法返回值或者方法的输入参数。

迪米特法则要求我们在设计系统时,应该尽量减少对象之间的交互,如果两个对象之间不必 彼此直接通信,那么这两个对象就不应当发生任何直接的相互作用,如果其中的一个对象需 要调用另一个对象的某一个方法的话,可以通过第三者转发这个调用。简言之,就是通过引 入一个合理的第三者来降低现有对象之间的耦合度。

在将迪米特法则运用到系统设计中时,要注意下面的几点:在类的划分上,应当尽量创建松 耦合的类,类之间的耦合度越低,就越有利于复用,一个处在松耦合中的类一旦被修改,不 会对关联的类造成太大波及;在类的结构设计上,每一个类都应当尽量降低其成员变量和成 员函数的访问权限;在类的设计上,只要有可能,一个类型应当设计成不变类;在对其他类 的引用上,一个对象对其他对象的引用应当降到最低。

2 案例说明

下面通过一个简单实例来加深对迪米特法则的理解:

Sunny软件公司所开发CRM系统包含很多业务操作窗口,在这些窗口中,某些界面控件之间存 在复杂的交互关系,一个控件事件的触发将导致多个其他界面控件产生响应,例如,当一个 按钮(Button)被单击时,对应的列表框(List)、组合框(ComboBox)、文本框(TextBox)、文本标 签(Label)等都将发生改变,在初始设计方案中,界面控件之间的交互关系可简化为如图1所示 结构:
重构前类图

在上图中,由于界面控件之间的交互关系复杂,导致在该窗口中增加新的界面控件时需要修改 与之交互的其他控件的源代码,系统扩展性较差,也不便于增加和删除新控件。

现使用迪米特对其进行重构。

在本实例中,可以通过引入一个专门用于控制界面控件交互的中间类(Mediator)来降低界面控 件之间的耦合度。引入中间类之后,界面控件之间不再发生直接引用,而是将请求先转发给 中间类,再由中间类来完成对其他控件的调用。当需要增加或删除新的控件时,只需修改中间类即可,无须修改新增控件或已有控件的源代码,重构后结构如下图所示:

重构后类图

3 设计模式七大原则

【设计模式】单一职责原则
【设计模式】开闭原则
【设计模式】里氏替换原则
【设计模式】依赖倒转原则
【设计模式】接口隔离原则
【设计模式】合成复用原则
【设计模式】迪米特法则

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值