设计原则之迪米特法则

定义:一个软件实体应当尽可能少地与其它实体发生交互作用。

问题:类与类之间的关系越密切,耦合度就越大,当其中一个类发生改变时,就会影响到另一个类的使用
方案:尽量降低类与类之间的耦合。

举个栗子:讲述一个打印公司成员ID的故事。。。
情况描述:总公司管理者需要打印出所有成员的ID,包括总公司成员名单和分公司成员ID。

违反迪米特法则的实现方式如下:

1. 新建一个总公司成员类Employee,包含一个员工ID。代码如下:


2. 新建一个分公司成员类SubEmployee,也包含一个员工ID。代码如下:


3. 新建一个分公司管理者类SubCompanyManager,包含一个获得分公司所有成员的ID的方法,代码如下:


4. 新建一个总公司管理者类CompanyManager,包含一个获得总公司所有成员的ID的方法和一个打印所有成员ID的方法。代码如下:


5. 在类LODFragment中使用类CompanyManager的对象来实现打印所有成员ID的效果。代码如下:


6. 运行后的效果,如下:


从上述实现方式可以看出,设计的主要问题是在类CompanyManager中,它与分公司成员Subemployee发生了直接的关系,从逻辑上讲总公司只需要与分公司耦合就行了,与分公司的成员没有任何关系,上述的做法显然增加了不必要也不恰当的耦合,根据迪米特法则,应该要避免类中出现这样非直接朋友关系的耦合。

修改方案:分公司管理者与分公司成员是直接朋友关系,所以我们将分公司所有成员ID的打印工作直接交给分公司管理者类来做,总公司直接调用打印就可以了,从而避免了与分公司成员发生耦合。

遵守迪米特法则的实现方式如下:

1. 在类SubCompanyManager中增加一个打印分公司所有成员ID的方法。代码如下:


2. 修改类CompanyManager中打印所有成员ID的方法,使用分公司管理者的对象调用分公司所有成员ID的打印方法。代码如下:


3. 类LODFragment不需要做更改,直接运行,效果如下:


综上所述,迪米特法则的初衷在于降低类之间的耦合。每个类都应尽量少地依赖其他类,因为这样才很容易使得系统的功能模块独立,非朋友关系之间不存在依赖关系。设计模式中的门面模式和中介模式都是迪米特法则应用的例子。

原则:高内聚,低耦合。
注意:可以直接相互作用的包括
1. 当前对象本身,this;
2. 以参数形式传入到当前对象方法中的对象;
3. 当前对象的成员对象;
4. 如果当前对象的成员对象是一个集合,那么集合中的元素也可以直接访问;
5. 当前对象创建的对象。

如果其他对象有相互耦合的情况,尽量采用第三者(友元类)来降低耦合。

优点:有利于软件功能的扩展和维护
缺点:不宜过分使用迪米特法则,不然会产生大量的中介和传递类,导致系统复杂度变大。

所以在采用迪米特法则时要反复权衡,既要做到结构清晰,又要做到高内聚低耦合。

总结就是进步,哪怕是一点点。 Github地址:https://github.com/chenxkang
原文地址:https://www.cnblogs.com/chenxkang/p/6668946.html