六大设计原则之五:迪米特法则

定义

迪米特法则(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,因为它是Teachercommand:方法的输入参数;另一个是Student,因为在Teachercommand:方法体中使用了Student

那么我们的Teacher有几个是直接的朋友?按照直接的朋友的定义“出现在成员变量、方法的输入输出参数中的类就是直接的朋友”,只有GroupLeaderTeacher的直接的朋友。

Teachercommand方法中创建了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;
}

在这个例子中,CoffeeMachineMan的直接好友,但问题是ManCoffeeMachine了解的太多了,其实人根本不关心咖啡机具体制作咖啡的过程。所以我们可以作如下优化:

优化后的咖啡机类,只暴露一个work方法,把制作咖啡的三个具体的方法addCoffeeBeanaddWatermakeCoffee设为私有:

@interface CoffeeMachine : NSObject

//只暴露一个方法
- (void)work;

@end

@implementation CoffeeMachine

- (void)work{
        //在work方法中执行完整的制作咖啡的过程
    [self addCoffeeBean];
    [self addWater];
    [self makeCoffee];
}

- (void)addCoffeeBean{
//自行脑补...
}

- (void)addWater{
//自行脑补...
}

- (void)makeCoffee{
//自行脑补...
}

@end

现在ManCoffeeMachine的了解只有一个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对外暴露的方法,减少ManCoffeeMachine的了解,从而降低了它们之间的耦合。

在实践中,只要做到只和直接的朋友交流减少对朋友的了解,就能满足迪米特法则。因此我们不难想象,迪米特法则的目的,是把我们的类变成一个个“肥宅”。“肥”在于一个类对外暴露的方法可能很少,但是它内部的实现可能非常复杂(这个解释有点牵强~)。“宅”在于它只和直接的朋友交流。在现实生活中“肥宅”是个贬义词,在日本“肥宅”已经成为社会问题。但是在程序中,一个“肥宅”的类却是优秀类的典范。

注意

迪米特法则的核心观念就是类间解耦,弱耦合。只有弱耦合了之后,类的复用才可以提高,类变更的风险才可以减低。但解耦是有限度的,除非是计算机的最小单元--二进制的0和1,否则都是存在耦合的。所以在实际项目中,需要适度地参考这个原则,避免过犹不及。

推荐阅读更多精彩内容