设计模式之迪米特法则

相关链接：
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 总结

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

最后编辑于 ：
©著作权归作者所有,转载或内容合作请联系作者
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念sama阅读 201,784评论 5赞 474
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 84,745评论 2赞 378
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
    开封第一讲书人阅读 148,702评论 0赞 335
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 54,229评论 1赞 272
  • 港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 63,245评论 5赞 363
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 48,376评论 1赞 281
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 37,798评论 3赞 393
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 36,471评论 0赞 256
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 40,655评论 1赞 295
  • 护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,485评论 2赞 318
  • 白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,535评论 1赞 329
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 33,235评论 3赞 318
  • 日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 38,793评论 3赞 304
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,863评论 0赞 19
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,096评论 1赞 258
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 42,654评论 2赞 348
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 42,233评论 2赞 341