迪米特法则(Law of Demeter) 简介
2014-12-21 23:20
330 查看
在Java里class设计经常会提到一些个原则或者规则
最出名的莫非是 封闭-开放原则了(closed-open principle)
而这次这个 Law of Demeter 也是挺重要的.
解释:
通常只看定义是不能理解的...
我们可以把这个法则分拆性两点.
1. 类设计中, 尽量降低成员的访问权限(最低是Private)
2. 类A 假如 不认识 类B, 那么类B不能直接访问类A的方法.
3. 假如类B要访问类A, 那么类B可以借组 第三个类C来实现, ( 类C是类A认识的类).
但是我们不能直接找联通的客服人员, 因为我们没有联通客服的私人号码.
这样则说明, 联通客服人员的服务方法不是Public的, 一般人不能直接访问.
SupportMM: 位于service包内
可见她的构造函数和service方法都是包内访问的.
客服类与客服MM类处于同1个包内,
客服类有个查找空闲mm的方法, 并且让空闲的mm去接客.
但是客服的service方法是对外的(public)
也就说所有客户都可以直接访问客服.
但是它可以通过客服来间接获得supportMM的服务.
![](http://image16.poco.cn/mypoco/myphoto/20141221/23/444127020141221231521058.png?683x360_130)
它有什么优点呢.
就是当我们修改supportMM的内容时, customer并不会受到任何影响.
也就是 松耦合的好处.
其实所有设计模式的目的无非两点:
1. 另业务思路更加清晰
2. 便于修改和扩展
最出名的莫非是 封闭-开放原则了(closed-open principle)
而这次这个 Law of Demeter 也是挺重要的.
一, 迪米特法则(Law of Demeter)的定义
迪米特法则(Law of Demeter)又叫作最少知识原则(Least Knowledge Principle 简写LKP),就是说一个对象应当对其他对象有尽可能少的了解,不和陌生人说话。英文简写为: LoD.解释:
通常只看定义是不能理解的...
我们可以把这个法则分拆性两点.
1. 类设计中, 尽量降低成员的访问权限(最低是Private)
2. 类A 假如 不认识 类B, 那么类B不能直接访问类A的方法.
3. 假如类B要访问类A, 那么类B可以借组 第三个类C来实现, ( 类C是类A认识的类).
二,一个例子
例如我们可以找联通客服mm来查询手机月费信息.但是我们不能直接找联通的客服人员, 因为我们没有联通客服的私人号码.
这样则说明, 联通客服人员的服务方法不是Public的, 一般人不能直接访问.
SupportMM: 位于service包内
package lawOfDemeter.service; import lawOfDemeter.Customer; public class SupportMM { private String name; protected SupportMM(String name){ this.name = name; } protected void service(Customer c){ System.out.println("Hello i am " + this.name); } }
可见她的构造函数和service方法都是包内访问的.
CustomerService: 位于service包内
这个是客服类.客服类与客服MM类处于同1个包内,
客服类有个查找空闲mm的方法, 并且让空闲的mm去接客.
但是客服的service方法是对外的(public)
也就说所有客户都可以直接访问客服.
package lawOfDemeter.service; import lawOfDemeter.Customer; public class CustomerService { public static void service(Customer c){ getFreeSupport().service(c); } private static SupportMM getFreeSupport(){ return new SupportMM("Inne"); // just a sample } }
Customer: 位于service包外
由于在包外, 所以Customer是不能直接访问SupportMM的package lawOfDemeter; import lawOfDemeter.service.*; public class Customer { public void askHelp(){ CustomerService.service(this); } }
但是它可以通过客服来间接获得supportMM的服务.
UML:
![](http://image16.poco.cn/mypoco/myphoto/20141221/23/444127020141221231521058.png?683x360_130)
三,小结
上面的那个例子是符合law of demeter的它有什么优点呢.
就是当我们修改supportMM的内容时, customer并不会受到任何影响.
也就是 松耦合的好处.
其实所有设计模式的目的无非两点:
1. 另业务思路更加清晰
2. 便于修改和扩展
相关文章推荐
- 迪米特法则 Law of Demeter
- 设计模式六大原则(5)迪米特法则(Law Of Demeter)
- IOS设计模式的六大设计原则之迪米特法则(LOD,Law Of Demeter)
- [设计模式原则]迪米特法则(Law of Demeter, LoD)
- IOS设计模式的六大设计原则之迪米特法则(LOD,Law Of Demeter)
- 迪米特法则 Law of Demeter
- 设计模式六大设计原则之迪米特法则(Law Of Demeter)
- 迪米特法则 (Law of Demeter, LoD)
- Java设计模式之迪米特法则(Law of Demeter, LoD)
- 迪米特法则(Law of Demeter)
- 迪米特法则(Law of Demeter)与领域模型行为
- 设计模式6大原则之迪米特法则(Law Of Demeter)
- 迪米特法则(Law of Demeter)
- 【六大设计原则】5. 迪米特法则 -Law of Demeter
- 设计模式六大原则(5):迪米特法则LOD(Law Of Demeter)
- IOS设计模式的六大设计原则之迪米特法则(LOD,Law Of Demeter)
- 6大设计原则之迪米特法则(Law Of Demeter)。
- 迪米特法则(Law of Demeter)
- IOS设计模式的六大设计原则之迪米特法则(LOD,Law Of Demeter)
- 迪米特法则(Law of Demeter)LoD