相关链接:
0. 设计模式之六大原则总结
1. 设计模式之单一职责原则
2. 设计模式之里式替换原则
3. 设计模式之依赖倒置原则
4. 设计模式之接口隔离原则
5. 设计模式之迪米特法则
6. 设计模式之开闭原则
1.1 定义
迪米特法则(Law of Demeter,LoD)是 1987 年秋天由 lan holland 在美国一个叫做迪米特的项目设计中提出的,它要求一个对象应该对其他对象有最少的了解,所以迪米特法则又叫最少知道原则。
1.2 理解
迪米特法则的意义在于降低类之间的耦合,每个类尽量减少对其他类的依赖,因此,很容易使得系统的功能模块独立,相互之间不存在(或很少有)依赖关系。
1.3 具体实践
实践中如何做到一个对象应该对其他对象有最少的了解呢?
我们把问题转化一下,如果我们把一个对象看做是一个人,那么要实现一个人应该对其他人有最少的了解,做到两点就足够了:
a. 只和直接的朋友交流
b. 减少对朋友的了解
1.3.1 只和直接的朋友交流
迪米特法则还有一个英文解释是:talk only to your immediate friends (只和直接的朋友交流)。
什么是朋友呢?
答:每个对象都必然会和其他的对象有耦合关系,两个对象之间的耦合就会成为朋友关系。
那什么又是直接朋友呢?
答:出现在成员变量、方法的输入输出参数中的类就是直接的朋友,只出现在方法体内部的类就不是直接的朋友,迪米特法则要求只和直接的朋友通信。
举个例子:
老师让班长清点全班同学人数,总共有三个类:老师 Teacher 、班长 GroupLeader 和 学生 Student。
Teacher 类:
@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
GroupLeader 类:
@interface GroupLeader : NSObject
//清点人数
- (void)count:(NSArray<Student *> *)students;
@end
@implementation GroupLeader
- (void)count:(NSArray<Student *> *)students{
//直接打印出学生的人数
NSLog(@"上课人数是:%d",(int)students.count);
}
@end
Student 类:
@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 在 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
修改后的 Teacher 类:
@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;
}
这样修改后,每个类都和直接的朋友交流,有效减少了类之间的耦合。
1.3.2 减少对朋友的了解
如何减少对朋友的了解?如果你的朋友是个超级大话痨,就算你不主动去问他,他也会在你面签叨叨叨的,把所有经历都讲给你听。所以,要减少对朋友的了解,就让他内敛一点,换做在一个类中,就是尽量减少一个类对外暴露的方法
举个例子:
一个人用咖啡机煮咖啡,有两个类:人 Person 和 咖啡机 CoffeeMachine
首先是咖啡机类 CoffeeMachine,制作咖啡需要三个方法:加咖啡豆、加水、制作咖啡:
@interface CoffeeMachine : NSObject
//加咖啡豆
- (void)addCoffeeBean;
//加水
- (void)addWater;
//制作咖啡
- (void)makeCoffee;
@end
@implementation CoffeeMachine
- (void)addCoffeeBean{
//自行脑补...
}
- (void)addWater{
//自行脑补...
}
- (void)makeCoffee{
//自行脑补...
}
@end
然后就是人类Person,该类只有一个方法makeCoffee,在该方法中使用咖啡机制作咖啡:
@interface Person : NSObject
//构造方法
- (instancetype)initWithCoffeeMachine:(CoffeeMachine *)coffeeMachine;
//制作咖啡方法
- (void)makeCoffee;
@end
@implementation Person
{
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];
//创建人
Person *person = [[Person alloc] initWithCoffeeMachine:coffeeMachine];
//人制作咖啡
[man makeCoffee];
return 0;
}
在这个例子中,CoffeeMachine 是 Person 的直接好友,但是 Person 对 CoffeeMachine 了解太多了,Person 只需要使用 CoffeeMachine制作就行,不需要关心咖啡机的具体制作过程,所以我们可以进行以下优化:
优化后的咖啡机类,只暴露一个 work 方法,把制作咖啡的三个具体方法设为私有:
@interface CoffeeMachine : NSObject
//只暴露一个方法
- (void)work;
@end
@implementation CoffeeMachine
- (void)work{
//在work方法中执行完整的制作咖啡的过程
[self addCoffeeBean];
[self addWater];
[self makeCoffee];
}
- (void)addCoffeeBean{
//自行脑补...
}
- (void)addWater{
//自行脑补...
}
- (void)makeCoffee{
//自行脑补...
}
@end
现在 Person 对 CoffeeMachine 的了解只有一个 work 方法了,所以 Person 类应该修改为:
@interface Person : NSObject
//构造方法
- (instancetype)initWithCoffeeMachine:(CoffeeMachine *)coffeeMachine;
//制作咖啡方法
- (void)makeCoffee;
@end
@implementation Person
{
CoffeeMachine *_coffeeMachine;
}
- (instancetype)initWithCoffeeMachine:(CoffeeMachine *)coffeeMachine{
self = [super init];
if (self) {
_coffeeMachine = coffeeMachine;
}
return self;
}
- (void)makeCoffee{
//使用咖啡机制作咖啡
[_coffeeMachine work];
}
@end
这样修改后,减少 CoffeeMachine 对外暴露的方法,减少 Person 对 CoffeeMachine 的了解,从而降低了它们的耦合。
在实践中,只要做到只和直接的朋友交流和减少对朋友的了解,就能满足迪米特法则。因此我们可以想象,迪米特法则就是把我们的类变成一个个”肥宅“:
- ”肥“在于一个类对外暴露的方法尽可能少,但是它内部的实现可能复杂
- ”宅“在于它只和最直接的朋友交流
1.4 总结
迪米特法则的核心观念就是类之间的解耦,弱耦合。这样类的复用才可以提高,类变更的风险才可以降低,但是在实际项目中,需要适度,过犹不及。