定义
迪米特法则(Law of Demeter, LoD)是1987年秋天由lan holland在美国东北大学一个叫做迪米特的项目设计提出的，它要求一个对象应该对其他对象有最少的了解，所以迪米特法则又叫做最少知识原则（Least Knowledge Principle, LKP）。
意义
迪米特法则的意义在于降低类之间的耦合。由于每个对象尽量减少对其他对象的了解，因此，很容易使得系统的功能模块功能独立，相互之间不存在（或很少有）依赖关系。
值得一提的是，这一法则却不仅仅局限于计算机领域，在其他领域也同样适用。比如，美国人就在航天系统的设计中采用这一法则。
实践
那么在实践中如何做到一个对象应该对其他对象有最少的了解呢？如果我们把一个对象看作是一个人，那么要实现“一个人应该对其他人有最少的了解”，做到两点就足够了：1.只和直接的朋友交流；2.减少对朋友的了解。下面就详细说说如何做到这两点。
只和直接的朋友交流
迪米特法则还有一个英文解释是：talk only to your immediate friends（只和直接的朋友交流）。什么是朋友呢？每个对象都必然会与其他的对象有耦合关系，两个对象之间的耦合就会成为朋友关系。那么什么又是直接的朋友呢？出现在成员变量、方法的输入输出参数中的类就是直接的朋友。迪米特法则要求只和直接的朋友通信。
注意：
只出现在方法体内部的类就不是直接的朋友，如果一个类和不是直接的朋友进行交流，就属于违反迪米特法则。
我们举一个例子说明什么是朋友，什么是直接的朋友。很简单的例子：老师让班长清点全班同学的人数。这个例子中总共有三个类：老师Teacher、班长GroupLeader和学生Student。
老师类：
@interface Teacher : NSObject
//命令班长清点人数
- (void)command:(GroupLeader *)groupLeader;
@end
@implementation Teacher
- (void)command:(GroupLeader *)groupLeader{
//创建全班学生的数组
NSMutableArray<Student *> *students = [[NSMutableArray alloc] init];
for (int i = 0; i < 20; i++) {
Student *student = [[Student alloc] init];
[students addObject:student];
}
//让班长清点人数
[groupLeader count:students];
}
@end
班长类：
@interface GroupLeader : NSObject
//清点人数
- (void)count:(NSArray<Student *> *)students;
@end
@implementation GroupLeader
- (void)count:(NSArray<Student *> *)students{
//直接打印出学生的人数
NSLog(@"上课人数是：%d",(int)students.count);
}
@end
学生类：
@interface Student : NSObject
@end
@implementation Student
@end
使用场景也是非常的简单：
int main(int argc, const char * argv[]) {
//创建班长对象
GroupLeader *groupLeader = [[GroupLeader alloc] init];
//创建老师对象
Teacher *teacher = [[Teacher alloc] init];
//老师命令班长清点人数
[teacher command:groupLeader];
return 0;
}
在这个例子中，我们的Teacher有几个朋友？两个，一个是GroupLeader，因为它是Teacher的command:方法的输入参数；另一个是Student，因为在Teacher的command:方法体中使用了Student。
那么我们的Teacher有几个是直接的朋友？按照直接的朋友的定义“出现在成员变量、方法的输入输出参数中的类就是直接的朋友”，只有GroupLeader是Teacher的直接的朋友。
Teacher在command方法中创建了Student的数组，和非直接的朋友Student发生了交流，所以，上述例子违反了迪米特法则。方法是类的一个行为，类竟然不知道自己的行为与其他的类产生了依赖关系，这是不允许的，严重违反了迪米特法则！
为了使上述例子符合迪米特法则，我们可以做如下修改：
修改后的GroupLeader：
@interface GroupLeader : NSObject
//构造方法，传入全班学生数组
- (instancetype)initWithStudents:(NSArray<Student *> *)students;
//清点人数方法
- (void)count;
@end
@implementation GroupLeader
{
NSArray<Student *> *_students;
}
- (instancetype)initWithStudents:(NSArray<Student *> *)students{
self = [super init];
if (self) {
_students = students;
}
return self;
}
- (void)count{
NSLog(@"上课人数是：%d",(int)_students.count);
}
@end
修改后的老师类：
@interface Teacher : NSObject
//命令班长执行清点人数的任务
- (void)command:(GroupLeader *)groupLeader;
@end
@implementation Teacher
- (void)command:(GroupLeader *)groupLeader{
[groupLeader count];
}
@end
修改后的使用场景：
int main(int argc, const char * argv[]) {
//创建学生数组
NSMutableArray *students = [[NSMutableArray alloc] init];
for (int i = 0; i < 20; i++) {
Student *student = [[Student alloc] init];
[students addObject:student];
}
//创建班长
GroupLeader *groupLeader = [[GroupLeader alloc] initWithStudents:students];
//创建老师
Teacher *teacher = [[Teacher alloc] init];
//老师命令班长执行清点人数命令
[teacher command:groupLeader];
return 0;
}
这样修改后，每个类都只和直接的朋友交流，有效减少了类之间的耦合。
减少对朋友的了解
如何减少对朋友的了解？如果你的朋友是个话痨加大喇叭，那就算你不主动去问他，他也会在你面前叨叨叨，把他所有的经历都讲给你听。所以，要减少对朋友的了解，请换一个内敛一点的朋友吧～换作在一个类中，就是尽量减少一个类对外暴露的方法。
举一个简单的例子说明一个类暴露方法过多的情况。这个例子描述的是一个人用咖啡机煮咖啡的过程，例子中只有两个类，一个是人，一个是咖啡机。
首先是咖啡机类CoffeeMachine，咖啡机制作咖啡只需要三个方法：1.加咖啡豆；2.加水；3.制作咖啡：
@interface CoffeeMachine : NSObject
//加咖啡豆
- (void)addCoffeeBean;
//加水
- (void)addWater;
//制作咖啡
- (void)makeCoffee;
@end
@implementation CoffeeMachine
- (void)addCoffeeBean{
//自行脑补...
}
- (void)addWater{
//自行脑补...
}
- (void)makeCoffee{
//自行脑补...
}
@end
然后就是人类Man，该类只有一个方法makeCoffee，在该方法中使用咖啡机制作咖啡：
@interface Man : NSObject
//构造方法
- (instancetype)initWithCoffeeMachine:(CoffeeMachine *)coffeeMachine;
//制作咖啡方法
- (void)makeCoffee;
@end
@implementation Man
{
CoffeeMachine *_coffeeMachine;
}
- (instancetype)initWithCoffeeMachine:(CoffeeMachine *)coffeeMachine{
self = [super init];
if (self) {
_coffeeMachine = coffeeMachine;
}
return self;
}
- (void)makeCoffee{
//使用咖啡机制作咖啡
[_coffeeMachine addCoffeeBean];
[_coffeeMachine addWater];
[_coffeeMachine makeCoffee];
}
@end
使用场景也非常的简单：
int main(int argc, const char * argv[]) {
//创建咖啡对象
CoffeeMachine *coffeeMachine = [[CoffeeMachine alloc] init];
//创建人
Man *man = [[Man alloc] initWithCoffeeMachine:coffeeMachine];
//人制作咖啡
[man makeCoffee];
return 0;
}
在这个例子中，CoffeeMachine是Man的直接好友，但问题是Man对CoffeeMachine了解的太多了，其实人根本不关心咖啡机具体制作咖啡的过程。所以我们可以作如下优化：
优化后的咖啡机类，只暴露一个work方法，把制作咖啡的三个具体的方法addCoffeeBean、addWater、makeCoffee设为私有:
@interface CoffeeMachine : NSObject
//只暴露一个方法
- (void)work;
@end
@implementation CoffeeMachine
- (void)work{
//在work方法中执行完整的制作咖啡的过程
[self addCoffeeBean];
[self addWater];
[self makeCoffee];
}
- (void)addCoffeeBean{
//自行脑补...
}
- (void)addWater{
//自行脑补...
}
- (void)makeCoffee{
//自行脑补...
}
@end
现在Man对CoffeeMachine的了解只有一个work方法了，所以Man类应该修改为：
@interface Man : NSObject
//构造方法
- (instancetype)initWithCoffeeMachine:(CoffeeMachine *)coffeeMachine;
//制作咖啡方法
- (void)makeCoffee;
@end
@implementation Man
{
CoffeeMachine *_coffeeMachine;
}
- (instancetype)initWithCoffeeMachine:(CoffeeMachine *)coffeeMachine{
self = [super init];
if (self) {
_coffeeMachine = coffeeMachine;
}
return self;
}
- (void)makeCoffee{
//使用咖啡机制作咖啡
[_coffeeMachine work];
}
@end
这样修改后，通过减少CoffeeMachine对外暴露的方法，减少Man对CoffeeMachine的了解，从而降低了它们之间的耦合。
在实践中，只要做到只和直接的朋友交流和减少对朋友的了解，就能满足迪米特法则。因此我们不难想象，迪米特法则的目的，是把我们的类变成一个个“肥宅”。“肥”在于一个类对外暴露的方法可能很少，但是它内部的实现可能非常复杂（这个解释有点牵强~）。“宅”在于它只和直接的朋友交流。在现实生活中“肥宅”是个贬义词，在日本“肥宅”已经成为社会问题。但是在程序中，一个“肥宅”的类却是优秀类的典范。
注意
迪米特法则的核心观念就是类间解耦，弱耦合。只有弱耦合了之后，类的复用才可以提高，类变更的风险才可以减低。但解耦是有限度的，除非是计算机的最小单元--二进制的0和1，否则都是存在耦合的。所以在实际项目中，需要适度地参考这个原则，避免过犹不及。
