迪米特法则——精选推荐
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
迪⽶特法则
1. 迪⽶特法则的概念
迪⽶特法则(Law of Demeter)⼜叫作最少知识原则(Least Knowledge Principle 简写LKP),⼀个类对于其他类知道的越少越好,就是说⼀个对象应当对其他对象有尽可能少的了解,只和朋友通信,不和陌⽣⼈说话。
英⽂简写为: LOD
迪⽶特法则可以简单说成:talk only to your immediate friends。
对于OOD来说,⼜被解释为下⾯⼏种⽅式:⼀个软件实体应当尽可能少的与其他实体发⽣相互作⽤。
每⼀个软件单位对其他的单位都只有最少的知识,⽽且局限于那些与本单位密切相关的软件单位。
迪⽶特法则不希望类之间建⽴直接的联系。
如果真的有需要建⽴联系,也希望能通过它的来转达。
因此,应⽤迪⽶特法则有可能造成的⼀个后果就是:系统中存在⼤量的中介类,这些类之所以存在完全是为了传递类之间的相互调⽤关系——这在⼀定程度上增加了系统的复杂度。
2. 迪⽶特法则的多种含义
⾸先是只和朋友交流(Only talk to your immediate friends),出现在成员变量、⽅法的输⼊输出参数中的类称为成员朋友类。
⽽出现在⽅法体内部的类不属于朋友类。
其次是朋友之间也是有距离的不能暴露太多,否则⼆次修改的时候,会让影响的范围增⼤。
这也要求类间public ⽅法不能肆⽆忌惮的暴露。
然后是⾃⼰的就是⾃⼰的,如果⼀个⽅法在类间关系中,放在⾃⾝类中既不增加类间关系,也对本类不产⽣负⾯影响就放置在⾃⾝类中。
最后是谨慎进⾏序列化操作。
3. 迪⽶特法则举例
举例⼦说明什么是朋友,什么是直接的朋友。
⽼师让班长清点全班同学的⼈数。
这个例⼦中总共有三个类:⽼师Teacher、班长GroupLeader和学⽣Student。
⽼师类:
//命令班长清点⼈数
- (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];
}
班长类:
//清点⼈数
- (void)count:(NSArray<Student *> *)students;
@implementation GroupLeader
- (void)count:(NSArray<Student *> *)students{
//直接打印出学⽣的⼈数
NSLog(@"上课⼈数是:%d",(int)students.count);
}
学⽣类:
@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;
}
分析:⽼师有⼏个朋友?有两个,⼀个是班长,因为是⽼师的命令⽅法的输⼊参数,另⼀个是学术,因为在⽼师的命令⽅法中使⽤了学⽣。
按照直接的朋友的定义“出现在成员变量、⽅法的输⼊输出参数中的类就是直接的朋友”,只有班长是⽼师的直接的朋友。
4. 迪⽶特法则的缺点
在系统⾥造出⼤量的⼩⽅法,这些⽅法仅仅是传递间接的调⽤,与系统的商务逻辑⽆关。
遵循类之间的迪⽶特法则会是⼀个系统的局部设计简化,因为每⼀个局部都不会和远距离的对象有直接的关联。
但是,这也会造成系统的不同模块之间的通信效率降低,也会使系统的不同模块之间不容易协调。