设计模式之禅5：迪米特法则

本文主要是介绍设计模式之禅5：迪米特法则，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

https://www.cnblogs.com/zh7791/p/7922960.html

定义：

一个对象应该对其他对象保持最少的了解。

问题由来：

类与类之间的关系越密切，耦合度越大，当一个类发生改变时，对另一个类的影响也越大。

解决方案：

尽量降低类与类之间的耦合。

 

PS:

 

自从我们接触编程开始，就知道了软件编程的总的原则：低耦合，高内聚。

无论是面向过程编程还是面向对象编程，只有使各个模块之间的耦合尽量的低，才能提高代码的复用率。

低耦合的优点不言而喻，但是怎么样编程才能做到低耦合呢？那正是迪米特法则要去完成的。

 

迪米特法则又叫最少知道原则，最早是在1987年由美国Northeastern University的Ian Holland提出。

通俗的来讲，就是一个类对自己依赖的类知道的越少越好。也就是说，对于被依赖的类来说，

无论逻辑多么复杂，都尽量地的将逻辑封装在类的内部，对外除了提供的public方法，不对外泄漏任何信息。

迪米特法则还有一个更简单的定义：只与直接的朋友通信。

首先来解释一下什么是直接的朋友：每个对象都会与其他对象有耦合关系，只要两个对象之间有耦合关系，我们就说这两个对象之间是朋友关系。

耦合的方式很多，依赖、关联、组合、聚合等。其中，我们称出现成员变量、方法参数、方法返回值中的类为直接的朋友，而出现在局部变量中的类则不是直接的朋友。

也就是说，陌生的类最好不要作为局部变量的形式出现在类的内部。

 

接下来用C#代码模拟发生的场景, 举个例子: 假如我们需要这样一个功能, 我们需要打印一个学校内所有班级的所有学生,

我们新建3个不同的类, Class(班级), Student(学生), School(学校) 

(1).班级类主要由一个ID和班级名称、一个学生列表, 另外还提供一个打印学生列表的Print()方法。

 

 public class Class{public int Id { get; set; }public string ClassName { get; set; }public List<Student> StudentList { get; set; }public void Print() //班级内里面预留打印学生的方法{foreach (Student s in this.StudentList){Console.WriteLine(" {0}Manage {1} ", s.GetType().Name, s.StudentName);}}}

 (2).学生类主要就由ID和学生姓名组成

public class Student{public int Id { get; set; }public string StudentName { get; set; }}

(3).School 主要构成同样, 另外也包含了一个Pirnt方法, 他负责打印班级名称和学生名称

public class School{public int Id { get; set; }public string SchoolName { get; set; }public List<Class> ClassList { get; set; }public void Print(){Console.WriteLine("Manage {0}", this.GetType().Name);foreach (Class c in this.ClassList){Console.WriteLine(" {0}Manage {1} ", c.GetType().Name, c.ClassName);List<Student> studentList = c.StudentList;foreach (Student s in studentList){Console.WriteLine(" {0}Manage {1} ", s.GetType().Name, s.StudentName);}}}

现在这个设计的主要问题出在School中，根据迪米特法则，只与直接的类发生通信，而Student类并不是School类的直接关系（以局部变量出现的耦合不属于直接关系），从逻辑上讲学校只与他的班级耦合就行了，与班级的学生并没有任何联系，

这样设计显然是增加了不必要的耦合。按照迪米特法则，应该避免类中出现这样非直接关系的耦合。修改后的代码如下:

public class School{public int Id { get; set; }public string SchoolName { get; set; }public List<Class> ClassList { get; set; }public void Print(){Console.WriteLine("Manage {0}", this.GetType().Name);foreach (Class c in this.ClassList){Console.WriteLine(" {0}Manage {1} ", c.GetType().Name, c.ClassName);c.Print();//List<Student> studentList = c.StudentList;//foreach (Student s in studentList)//{//    Console.WriteLine(" {0}Manage {1} ", s.GetType().Name, s.StudentName);//}}}}

修改后，调用班级打印学生名称的方法，学校直接调用来打印，从而避免了与班级的学生发生耦合。

 

迪米特法则的初衷是降低类之间的耦合，由于每个类都减少了不必要的依赖，因此的确可以降低耦合关系。

但是凡事都有度，虽然可以避免与非直接的类通信，但是要通信，必然会通过一个“中介”来发生联系，例如本例中，总公司就是通过分公司这个“中介”来与分公司的员工发生联系的。

过分的使用迪米特原则，会产生大量这样的中介和传递类，导致系统复杂度变大。所以在采用迪米特法则时要反复权衡，既做到结构清晰，又要高内聚低耦合。

何谓生死、功名利禄、皆为浮云

 

------------------------------------------------------------------------------------------------------

（Law of Demeter,LoD）也称为最少知识原则（Least KnowLedge Principle, LKP），虽然名字不同，但描述的是同一个规则：一个对象应该对其他对象有最少的了解。通俗地讲，一个类应该对自己需要耦合或者调用的类知道得最少，你（被耦合或调用的类）的内部是如何复杂都和我没关系，那是你的事情，我就知道你提供了这么多的public方法，我就调用这么多，其他的我一概不关心。

迪米特法则对类的低耦合提供了明确的要求，其包含以下四层含义：

1、只和朋友交流

迪米特法则还有一个英文解释：Only talk to your immedate friends（只与直接的朋友通信）。什么叫直接的朋友呢？每个对象都必然会与其他对象有耦合关系，两个对象直接的耦合就成为朋友关系，这种关系的类型有很多，例如组合、聚合、依赖等。下面举例介绍说明如何才能做到只与直接的朋友交流。

例如，老是想让体育委员确认以下女生人数，我们来看怎么用程序来实现，类图如图：

Teacher类的commond方法负责发送命令给体育委员，命令他清点女生，其实现过程如下：

老师只有一个commond方法，先定义出所有的女生，然后发命令给体育委员，去清点以下女生的数量。体育委员GroupLeader的实现过程如下：

老师类和体育委员类都对女生类产生了依赖，而且女生类不需要执行任何动作，因此定义一个空类，如图：

故事中的三个角色都有了，在定义一个场景来描述这个故事，实现过程如下：

运行结果：

体育委员按照老师的要求对女生进行了清点，并得出了数量。我们回过头来思考一下这个程序有什么问题，首先确定Teacher有几个朋友类，他仅有一个朋友类：GroupLeader。为什么Girl不是朋友类呢？Teacher也对他产生了依赖关系啊！朋友类的定义是这样的：出现在成员变量，方法的输入输出中的类称为成员朋友类。迪米特法则告诉我们一个类只和朋友类交流，但是我们刚刚定义的commond方法却与Girl类有了交流，声明了一个List动态数组，也就是与一个陌生的类Girl有了交流，这样就破坏了Teacher的健壮性。方法是类的一个行为，类竟然不知道与其他类产生了依赖关系，这是不允许的，严重违反了迪米特法则。

可以这样子修改，在类图中去掉Teacher对Girl类的依赖关系，修改后的Teacher类如下：

修改后的体育委员类:

修改后的场景类：

把Teacher中对List的初始化移动到了场景类中，同时在GroupLeader中增加了对Girl的注入，避开了Teacher类对陌生类Girl的访问，降低了系统间的耦合，提高了系统的健壮性。

注意：一个类只和朋友交流，不与陌生类交流，类与类之间的关系是建立在类间的，而不是方法间，因此一个方法尽量不引入一个类中不存在的对象，当然JDK API提供的类除外。

2、朋友间也是有距离的

朋友间是有距离的，太远关系逐渐疏远，最终形成陌路；太近就互相刺伤，必须保持一个合适的距离。迪米特法则就是对这个距离的描述，即使是朋友类之间也不能无话不说，无所不知。

例如，我们在安装软时，经常有一个导向动作，第一步是确认是否安装，第二步是确认License，然后再选择安装目录；这是一个典型的顺序执行动作，具体到程序中就是：调用一个或者多个类，先执行第一个方法，然后是第二个方法，根据返回结果再来看是否调用第三个方法，其类图如下：

很简单的类图，实现软件安装的过程，其中first方法定义第一步做什么，second方法定义第二步做什么，其实现过程如下：

InstallSoftware类：

程序虽然简单，隐藏的问题可不简单，思考一下程序有什么问题。Wizard类把太多的方法暴露给InstallSoftware类，两者的朋友关系太紧密了，耦合关系变得异常牢固。如果要将Wizard类中的first方法返回值的类型由int改为boolean，就需要修改InstallSoftware类，从而把修改变更的风险扩散开来。因此这样的耦合是极度不合适的，我们需要重新对设计进行重构，重构后的类图如下：

   在Wizard类方法中增加一个installWizard方法，对安装过程进行封装，同时把原有的三个public方法修改为private方法，如下所示：

修改后的InstallSoftware类：

通过这样的重构后，Wizard类对外只公布了一个public方法，即使要修改first的返回值，影响的也只是Wizard本身，其他类不受影响，这显示了类的高内聚特性。

注意：迪米特法则要求类“羞涩”一点，尽量不要对外公布太多的public方法和非静态的public变量，尽量内敛，多使用private、protected等访问权限。

3、是自己的就是自己的

在实际应用中经常出现这样一个方法，放在本类中也可以，放在其他类中也没错，那怎么去衡量呢？你可以坚持这样一个原则：如果一个方法放在本类中，即不增加类间关系，也不对本类产生负面影响，就放置在本类中。

总结：迪米特法则的核心观念就是类间解耦，弱耦合，只有弱耦合了以后，类的复用率才能提高。其要求的结果就是产生了大量的中转或跳转类，导致系统的复杂性提高，同时也为维护带来了难度。

//以上内容选自秦小波著<<设计模式之禅>>

顶

0

踩

这篇关于设计模式之禅5：迪米特法则的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---