设计模式之迪米特法则

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 总结

迪米特法则的核心观念就是类之间的解耦，弱耦合。这样类的复用才可以提高，类变更的风险才可以降低，但是在实际项目中，需要适度，过犹不及。

 

 

2人点赞

 

框架设计

 

 

作者：code_ce
链接：https://www.jianshu.com/p/7413be8aabf5
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。