五、设计模式的六大设计原则之迪米特法则(LOD,Law Of D
1. 何为迪米特法则
狭义的迪米特法则定义：也叫最少知识原则(LKP，Least Knowledge Principle)。如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中的一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。
广义的迪米特法则定义：一个模块设计得好坏的一个重要的标志就是该模块在多大的程度上将自己的内部数据与实现有关的细节隐藏起来。信息的隐藏非常重要的原因在于，它可以使各个子系统之间解耦，从而允许它们独立地被开发、优化、使用阅读以及修改。
定义解读：
迪米特法则通常被表述为：Only talk to your immediate friends ( 只和离你最近的朋友进行交互)。什么是最近的朋友？我们知道，每个对象都会与其他对象之间有耦合关系，只要两个对象之间有耦合关系，我们就说这两个对象之间是朋友关系。耦合的方式很多，如依赖、关联、组合、聚合等。其中，我们称出现在成员变量、方法参数、方法返回值中的类为最近的朋友，而出现在局部变量中的类则不是最近的朋友。迪米特法则是很好的解耦合手段之一。在网上看到的比较形象的说明这个法则的示例：
如果你想让你的狗狗跑的话，你会对狗狗说还是对四条狗腿说？
如果你去店里买东西，你会把钱交给店员，还是会把钱包交给店员让他自己拿？
优点：
迪米特法则使对象之间的耦合降到最小，符合高内聚低耦合的特性，从而使得类具有很好的可读性和可维护性。
后面介绍的设计模式中，外观模式（Facade）和中介者模式（Mediator），都是迪米特法则应用的例子。
2. 情景设置
类与类之间的关系越密切，耦合度越大，当一个类发生改变时，对另一个类的影响也越大。
解决方案
使用迪米特法则，降低类与类之间的耦合。
3. 代码示例
示例中有犯人、亲人、狱友这些对象，接下来我就通过三个亲人去监狱看犯人的设计来说明如何理解迪米特法则(该示例是从网上摘录的，这里使用Objective-C语言进行重新编写，并添加了UML图来进行理解，最后用迪米特法则和依赖倒置原则相结合进行了扩展)。
设计1：亲人和狱友有交流(违反迪米特法则，因为对于亲人来说，狱友是陌生人)。
UML图如图3-1所示：
图3-1
代码实现：
（1）Inmates
@interface Inmates : NSObject
- (void)weAreFriend;
@end
@implementation Inmates
- (void)weAreFriend
{
NSLog(@"狱友说：我们是狱友...");
}
@end
（2）Prisoners
@interface Prisoners : NSObject
{
Inmates *_inmates;
}
@property (nonatomic, retain) Inmates *inmates;
- (Inmates *)helpEachOther;
@end
@implementation Prisoners
@synthesize inmates = _inmates;
- (id)init
{
self = [super init];
if (self != nil) {
_inmates = [[Inmates alloc] init];
}
return self;
}
- (Inmates *)helpEachOther
{
NSLog(@"家人说：你和狱友之间应该互相帮助...");
return _inmates;
}
@end
（3）Family
@interface Family : NSObject
- (void)visitPrisoner:(Prisoners *)prisoners;
@end
@implementation Family
- (void)visitPrisoner:(Prisoners *)prisoners
{
//家人希望犯人与狱友互帮互助
Inmates *inmates = [prisoners helpEachOther];
//狱友说，我们是狱友
[inmates weAreFriend];
}
@end
（4）客户端调用
Family *family = [[Family alloc] init];
Prisoners *prisoners = [[Prisoners alloc] init];
[family visitPrisoner:prisoners];
从上面可以看到，家人告诉犯人要与狱友好好相处，而狱友却冒出来说话。这显然越界了，因为监狱只允许家人探望犯人，而不是随便谁都可以见。而家人和狱友有了沟通是违背迪米特法则的，所以我们需要将家人和狱友隔离开，对其进行重构。
设计2：家人和狱友没有直接的交流。
UML图如图3-2所示：
图3-2
代码实现：
（1）Inmates
@interface Inmates : NSObject
- (void)weAreFriend;
@end
@implementation Inmates
- (void)weAreFriend
{
NSLog(@"狱友说：我们是狱友...");
}
@end
（2）Prisoners
@interface Prisoners : NSObject
{
Inmates *_inmates;
}
@property (nonatomic, retain) Inmates *inmates;
- (void)helpEachOther;
@end
@implementation Prisoners
@synthesize inmates = _inmates;
- (id)init
{
self = [super init];
if (self != nil) {
_inmates = [[Inmates alloc] init];
}
return self;
}
- (void)helpEachOther
{
NSLog(@"家人说：你和狱友之间应该互相帮助...");
[_inmates weAreFriend];
}
@end
（3）Family
@interface Family : NSObject
- (void)visitPrisoner:(Prisoners *)prisoners;
@end
@implementation Family
- (void)visitPrisoner:(Prisoners *)prisoners
{
[prisoners helpEachOther];
}
@end
（4）客户端调用
Family *family = [[Family alloc] init];
Prisoners *prisoners = [[Prisoners alloc] init];
[family visitPrisoner:prisoners];
设计3：和依赖倒置原则相结合。
UML图如图3-3所示：
图3-3
代码实现：
（1）Inmates
@protocol InmatesDelegate <NSObject>
- (void)weAreFriend;
@end
@interface Inmates : NSObject<InmatesDelegate>
@end
@implementation Inmates
- (void)weAreFriend
{
NSLog(@"狱友说：我们是狱友...");
}
@end
（2）Prisoners
@interface Prisoners : NSObject
- (void)helpEachOther;
@end
@implementation Prisoners
- (void)helpEachOther
{
NSLog(@"家人说：你和狱友之间应该互相帮助...");
}
@end
（3）Family
@interface Family : NSObject
- (void)visitPrisoner:(Prisoners *)prisoners inmates:(id<InmatesDelegate>)inmates;
@end
@implementation Family
- (void)visitPrisoner:(Prisoners *)prisoners inmates:(id<InmatesDelegate>)inmates
{
//家人希望犯人与狱友互帮互助
[prisoners helpEachOther];
//狱友说，我们是狱友
[inmates weAreFriend];
}
@end
（4）客户端调用
Family *family = [[Family alloc] init];
Prisoners *prisoners = [[Prisoners alloc] init];
id<InmatesDelegate> inmates = [[Inmates alloc] init];
[family visitPrisoner:prisoners inmates:inmates];
从上面看到，和依赖倒置原则相结合之后的设计，也是符合迪米特原则的：如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中的一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用，这里的第三者就是接口InmatesDelegate。大话设计模式那本书里面介绍的小菜找IT部修电脑的例子，也是迪米特原则和依赖倒置原则相结合的：在那个例子里面，IT部就是接口(类似这里的InmatesDelegate)，小张小李就是具体类(类似这里的Inmates)，由于IT部是抽象的，哪怕里面的人都离职或换了新人，小菜的电脑出问题也还是可以找IT部解决，而不需要认识其中的同事，纯靠关系帮忙。
