设计模式6大设计原则解读——迪米特法则

上一篇我们解读了接口隔离原则，今天来说一下迪米特法则。

1. 迪米特法则（Law of Demeter，LoD）也称最少知识原则（Least Knowledge Principle，LKP）一个对象应该对其他对象有最少的了解。
   定义：
   1、只和朋友交流（出现在成员变量、方法的输入输出参数中的类称为成员朋友类，而出现在方法体内部的类不属于朋友）
   2、朋友间也是有距离的
   3、是自己的就是自己的（如果一个方法放在本类中，既不增加类间关系，也对本类不产生负面影响，就放置在本类中）
   原文定义：
   Only talk to your immediate friends(只与直接的朋友通信)
   简要解读：一个类应该对自己需要耦合或调用的类知道的最少，需要耦合或调用的类的内部如何复杂和我调用的类都没有关系，我只关心调用的你的类中的public的方法。
   场景再现：类与类之间的关系越密切，耦合度越大，当这个类发生改变时，对另一个类的影响也越大。
   解决方案：尽量降低类与类之间的耦合。
   理解：软件开发的主要原则就是高内聚、低耦合，各个模块之间的耦合越低才能提高代码的复用率。
   1、只和朋友交谈
   首先来解释一下什么是直接的朋友：每个对象都会与其他对象有耦合关系，只要两个对象之间有耦合关系，我们就说这两个对象之间是朋友关系。耦合的方式很多，依赖、关联、组合、聚合等。其中，我们称出现成员变量、方法参数、方法返回值中的类为直接的朋友，而出现在局部变量中的类则不是直接的朋友。也就是说，陌生的类最好不要作为局部变量的形式出现在类的内部。下面我们举一个例子来说明直接朋友类。

   

   Teacher类的command方法命令体委去清点女生人数，实现代码过程如下：

   

   体委的类的实现过程如下：

   

   老师类和体委类都对女生类产生了依赖关系，但是女生类什么都没有做，因此只是一个空类，代码如下图：
   

   场景类代码如下图所示：

   

   运行结果如下图：

   

   下面我们先来看一下Teacher类只有一个GroupLeader的朋友类，Teacher类虽然也对Girl类产生了依赖，但Girl类却不是Teacher的朋友类，根据上面朋友类的定义可以看出，Girl这个类是出现在command方法内部的类，所以不属于直接朋友类。迪米特法则告诉我们一个类只和朋友类交流，但我们定义的command方法却与Girl类有了交流，这样就破坏了Teacher类的健壮性。方法是类的一个行为，类不知道自己的行为与其他类产生了依赖关系，这是不允许的，严重违反了迪米特法则。那么接下来我们对以上程序进行改进，修改后的类图如下：

   

   在类图中去掉Teacher类对Girl类的依赖，修改后的Teacher类图如下：

   

   修改后体委的实现代码如下：

   

   场景类代码如下：

   

   经过以上修改，降低了系统间的耦合性，提高了程序的健壮性。
   2、朋友间也是有距离的
   即使两个类是朋友也不能无话不说，两个朋友类之间也要遵循一定的规则，下面我们通过安装软件的步骤来讲解这个规定。软件安装过程类图如下：

   

   导向类的实现代码如下图：

   

   在Wizard类中定义了三个步骤，每个步骤都有相关的业务逻辑完成指定的任务，我们使用一个随机函数来代替业务执行的返回值，软件安装类代码如图所示：

   

   场景类代码如下：

   

   以上这个示例程序虽然简单，但是我们会发现一个问题，Wizard类把很多方法暴露给了InstallSoftware类，两者关系太紧密了，因此我们需要调整这种关系。调整后的类图如下：

   

   修改后的导向类的实现代码如下图：

   

   经过重构之后即使first方法发生了改变，影响的也仅仅是Wizard类本身。修改后的InstallSoftware类代码如下：

   

   场景类不用修改，经过我们的重构，类之间的耦合性降低了，结构也变得清晰，变更引起的风险也降低了。
   一个类公开的public方法或属性越多，修改时涉及到的面也越大，变更引起的风险扩散也就越大，因此在设计时也不要将朋友类之间设计的太过亲密，尽量减少public的方法和属性。迪米特法则要求尽量内敛一些，尽量多使用private、protected等访问权限。
   3、自己的就是自己的
   在实际开发过程中，很容易出现这种情况，比如说这个方法放到这个类也可以，放到另一个类也可以。这时我们需要遵守一个原则：如果一个方法放到本类中，既不增加类间关系，也对本类不产生负面影响那就可以放在本类中。

迪米特法则的核心观念就是类间解耦，耦合低的情况下类的复用性才能更好。在使用迪米特法则的时候应权衡既能使代码结构清晰，也能做到高内聚低耦合。在项目的应用中，应该适度的应用这些原则才能做出更好的设计。

迪米特法则就说到这里，下一篇我们将介绍开闭原则。