迪米特法则来自于1987年美国东北大学(Northeastern University)一个名为“Demeter”的研究项目。迪米特法则又称为最少知识原则(LeastKnowledge Principle, LKP)，其定义如下：
迪米特法则(Law of Demeter, LoD)：一个软件实体应当尽可能少地与其他实体发生相互作用。
如果一个系统符合迪米特法则，那么当其中某一个模块发生修改时，就会尽量少地影响其他模块，扩展会相对容易，这是对软件实体之间通信的限制，迪米特法则要求限制软件实体之间通信的宽度和深度。迪米特法则可降低系统的耦合度，使类与类之间保持松散的耦合关系。
迪米特法则还有几种定义形式，包括：不要和“陌生人”说话、只与你的直接朋友通信等，在迪米特法则中，对于一个对象，其朋友包括以下几类：
(1) 当前对象本身(self)；
(2) 以参数形式传入到当前对象方法中的对象；
(3) 当前对象的成员对象；
(4) 如果当前对象的成员对象是一个集合，那么集合中的元素也都是朋友；
(5) 当前对象所创建的对象。
任何一个对象，如果满足上面的条件之一，就是当前对象的“朋友”，否则就是“陌生人”。在应用迪米特法则时，一个对象只能与直接朋友发生交互，不要与“陌生人”发生直接交互，这样做可以降低系统的耦合度，一个对象的改变不会给太多其他对象带来影响。
迪米特法则要求我们在设计系统时，应该尽量减少对象之间的交互，如果两个对象之间不必彼此直接通信，那么这两个对象就不应当发生任何直接的相互作用，如果其中的一个对象需要调用另一个对象的某一个方法的话，可以通过第三者转发这个调用。简言之，就是通过引入一个合理的第三者来降低现有对象之间的耦合度。
在将迪米特法则运用到系统设计中时，要注意下面的几点：在类的划分上，应当尽量创建松耦合的类，类之间的耦合度越低，就越有利于复用，一个处在松耦合中的类一旦被修改，不会对关联的类造成太大波及；在类的结构设计上，每一个类都应当尽量降低其成员变量和成员函数的访问权限；在类的设计上，只要有可能，一个类型应当设计成不变类；在对其他类的引用上，一个对象对其他对象的引用应当降到最低。
举例
我是闲着没事的时候就喜欢看书，比如耳根、天蚕土豆这些人的书。如果用编程来模拟这个场景的话，涉及到了三样东西：手机、阅读器、书。一切从简，如下：
书类
@interface Book : NSObject
@property (nonatomic, copy) NSString *name;
@end
@implementation Book
- (NSString *)name {
if (_name.length == 0) {
_name = @"三寸人间";
}
return _name;
}
@end
阅读器类
@interface App : NSObject
- (void)readBook:(Book *)book;
@end
@implementation App
- (void)readBook:(Book *)book {
NSLog(@">>>book name :%@", book.name);
}
@end
手机类
@interface Phone : NSObject
- (void)readBook;
@end
@implementation Phone
- (void)readBook {
App *app = [App new];
Book *book = [Book new];
[app readBook:book];
}
@end
使用
Phone *phone = [Phone new];
[phone readBook];
Log
>>>book name :三寸人间
看着是没有啥问题的，其实是有问题的。现实中，我们打开手机，打开阅读器，然后从阅读器里面打开书籍，也就是说，手机里面有阅读器，阅读器里面有书籍，手机是通过阅读器来看书籍的，手机和阅读器是朋友，阅读器和书籍是朋友。
就上面代码而言，在Phone里面既有App又有Book，这就出现了手机和阅读器、书籍都构成了朋友关系，这就不是正确的迪米特法则：朋友的朋友就是陌生人。
可做一下修改：
书籍类
@interface LoDBook : NSObject
@property (nonatomic, copy) NSString *name;
@end
@implementation LoDBook
- (NSString *)name {
if (_name.length == 0) {
_name = @"大主宰";
}
return _name;
}
@end
阅读器类
@interface LoDApp : NSObject
- (void)readBook;
@end
@implementation LoDApp
- (void)readBook {
LoDBook *book = [LoDBook new];
NSLog(@">>> LoD book name:%@", book.name);
}
@end
手机类
@interface LoDPhone : NSObject
- (void)read;
@end
@implementation LoDPhone
- (void)read {
LoDApp *app = [LoDApp new];
[app readBook];
}
@end
总结
优点
- 降低了类之间的耦合度，提高了模块的相对独立性。
- 由于亲合度降低，从而提高了类的可复用率和系统的扩展性。
缺点
- 会造成系统的不同模块之间的通信效率降低，使系统的不同模块之间不容易协调。
- 因为迪米特法则要求类与类之间尽量不直接通信，如果类之间需要通信就通过第三方转发的方式，这就直接导致了系统中存在大量的中介类，这些类存在的唯一原因是为了传递类与类之间的相互调用关系，这就毫无疑问的增加了系统的复杂度。
项目中使用迪米特法则要适度，需要反复权衡，确保高内聚和低耦合的同时，保证系统的结构清晰。
