http://zhangyi.xyz/demeter-law-and-refactoring
https://www2.ccs.neu.edu/research/demeter/demeter-method/LawOfDemeter/paper-boy/demeter.pdf
http://blog.csdn.net/zhengzhb/article/details/7296930
定义：一个对象应该对其他对象保持最少的了解。
https://www2.ccs.neu.edu/research/demeter/demeter-method/LawOfDemeter/paper-boy/demeter.pdf
这个原则认为，任何一个对象或者方法，它应该只能调用下列对象：
- 该对象本身
- 作为参数传进来的对象（也可以是该对象的字段）
- 在方法内创建的对象
这个原则用以指导正确的对象协作，分清楚哪些对象应该产生协作，哪些对象则对于该对象而言，又应该是无知的。如何理解这个原则？我们可以看看David Bock就该原则给出的一个绝佳案例。假设一个超市购物的场景，顾客（Customer）到收银台结账，收银员（Paper Boy）负责收钱
让我们将PaperBoy中
charge()方法的代码翻译成这幕小话剧的对白。
“把钱包交出来！”收银员算出顾客要买的商品总价后，“温柔”地对顾客说道。
顾客言听计从，赶紧将钱包掏出来，恭恭敬敬地递给收银员。
接过钱包，收银员毫不客气地打开，检查里面的钱够不够。噢，不错，钱够了。收银员从钱包取出钱，心满意足地笑了。
顾客言听计从，赶紧将钱包掏出来，恭恭敬敬地递给收银员。
接过钱包，收银员毫不客气地打开，检查里面的钱够不够。噢，不错，钱够了。收银员从钱包取出钱，心满意足地笑了。
判断一段代码是否违背了迪米特法则，有一个小窍门，就是看调用代码是否出现形如
a.m1().m2().m3().m4()之类的代码。这种代码在Martin Fowler《重构》一书中，被名为“消息链条（Message Chain）”，有人更加夸张地名其为“火车残骸”。车祸现场啊，真是惨不忍睹。
那么，如下代码是否这样的残骸呢？
1 2 3 4 5 | str.split("&") .stream() .map(str -> str.contains(elementName) ? str.replace(elementName + "=", "") : "") .filter(str -> !str.isEmpty()) .reduce("", (a, b) -> a + "," + b); |
不是的。这样的代码我们一般称之为“流畅接口或连贯接口（Fluent Interface）”。二者的区别在于观察形成链条的每个方法返回的是别的对象，还是对象自身。如果返回的是别的对象，就是消息链条。所谓
m1().m2().m3().m4()的调用，其实是调用者不需要也不想知道的“知识”，把这些中间过程的细节暴露出来没有意义，调用者关心的是最终结果；而上述代码中的map()与filter()等方法其实返回的还是Stream类。这一调用方式其初衷并非告知中间过程的细节，而是一种声明式的DSL表达，调用者可以自由地组合它们定义：一个对象应该对其他对象保持最少的了解。
问题由来：类与类之间的关系越密切，耦合度越大，当一个类发生改变时，对另一个类的影响也越大。
解决方案：尽量降低类与类之间的耦合。
自从我们接触编程开始，就知道了软件编程的总的原则：低耦合，高内聚。无论是面向过程编程还是面向对象编程，只有使各个模块之间的耦合尽量的低，才能提高代码的复用率。低耦合的优点不言而喻，但是怎么样编程才能做到低耦合呢？那正是迪米特法则要去完成的。
迪米特法则又叫最少知道原则，最早是在1987年由美国Northeastern University的Ian Holland提出。通俗的来讲，就是一个类对自己依赖的类知道的越少越好。也就是说，对于被依赖的类来说，无论逻辑多么复杂，都尽量地的将逻辑封装在类的内部，对外除了提供的public方法，不对外泄漏任何信息。迪米特法则还有一个更简单的定义：只与直接的朋友通信。首先来解释一下什么是直接的朋友：每个对象都会与其他对象有耦合关系，只要两个对象之间有耦合关系，我们就说这两个对象之间是朋友关系。耦合的方式很多，依赖、关联、组合、聚合等。其中，我们称出现成员变量、方法参数、方法返回值中的类为直接的朋友，而出现在局部变量中的类则不是直接的朋友。也就是说，陌生的类最好不要作为局部变量的形式出现在类的内部。
举一个例子：有一个集团公司，下属单位有分公司和直属部门，现在要求打印出所有下属单位的员工ID。先来看一下违反迪米特法则的设计。
现在这个设计的主要问题出在CompanyManager中，根据迪米特法则，只与直接的朋友发生通信，而SubEmployee类并不是CompanyManager类的直接朋友（以局部变量出现的耦合不属于直接朋友），从逻辑上讲总公司只与他的分公司耦合就行了，与分公司的员工并没有任何联系，这样设计显然是增加了不必要的耦合。按照迪米特法则，应该避免类中出现这样非直接朋友关系的耦合。修改后的代码如下:
class CompanyManager{
public List<Employee> getAllEmployee(){
List<Employee> list = new ArrayList<Employee>();
for(int i=0; i<30; i++){
Employee emp = new Employee();
//为总公司人员按顺序分配一个ID
emp.setId("总公司"+i);
list.add(emp);
}
return list;
}
public void printAllEmployee(SubCompanyManager sub){
sub.printEmployee();
List<Employee> list2 = this.getAllEmployee();
for(Employee e:list2){
System.out.println(e.getId());
}
}
}
修改后，为分公司增加了打印人员ID的方法，总公司直接调用来打印，从而避免了与分公司的员工发生耦合。
迪米特法则的初衷是降低类之间的耦合，由于每个类都减少了不必要的依赖，因此的确可以降低耦合关系。但是凡事都有度，虽然可以避免与非直接的类通信，但是要通信，必然会通过一个“中介”来发生联系，例如本例中，总公司就是通过分公司这个“中介”来与分公司的员工发生联系的。过分的使用迪米特原则，会产生大量这样的中介和传递类，导致系统复杂度变大。所以在采用迪米特法则时要反复权衡，既做到结构清晰，又要高内聚低耦合。
迪米特法则：Law Of Demeter，LoD。
也被称为最少知识原则，Least Knowledge Principle，LKP。
就是说一个对象应该对其他对象保持最少的了解。正如最少知识原则这个定义一样，一个类应该对其耦合的其他类或所调用的类知道得最少。所耦合的类内部无论如何复杂，怎么实现的我都不需要知道，我只调用你public出来的这些方法，其他都不用知道。
看到这里很多人都会明白，这种场景在实际开发中是非常常见的一种情况。对象A需要调用对象B的方法，对象B有需要调用对象C的方法……就是常见的getXXX().getXXX().getXXX()……类似于这种代码。如果你发现你的代码中也有这样的代码，那就考虑下是不是违反迪米特法则，是不是要重构一下了。
- 类A只与最直接的朋友类B通信，不与类C通信；
- 类A只调用类B提供的方法即可，不用关心类B内部是如何实现的（至于B是怎么调用的C，这些A都不用关心）。
迪米特法则的目的是让类之间解耦，降低耦合度。只有这样，类的可复用性才能提高。
但是迪米特法则也有弊端，它会产生大量的中转类或跳转类，导致系统的复杂度提高。
所以我们不要太死板的遵守这个迪米特法则，在系统设计的时候，在弱耦合和结构清晰之间反复权衡。尽量保证系统结构清晰，又能做到低耦合。
- Each unit should have only limited knowledge about other units: only units "closely" related to the current unit.
- Each unit should only talk to its friends; don't talk to strangers.
- Only talk to your immediate friends.
The fundamental notion is that a given object should assume as little as possible about the structure or properties of anything else (including its subcomponents), in accordance with the principle of "information hiding".
a module should not know about the inner details of the objects it manipulates. If a code depends upon internal details of a particular object, there is good chance that it will break as soon as internal of that object changes.
One mistake many Java programmer makes it exposing internal detail of object using getter methods and this is where principle of least knowledge alerts you.
In short, the Law of Demeter aims to keep you from doing things like this:
objectA.getObjectB().getObjectC().doSomething(); ===> contrvsery
When you write code like this, not only are you exposing yourself to changes in the ObjectA class, you're also exposing yourself to changes that may occur in ObjectB and ObjectC as well.
Forces
- Your classes will be "loosely coupled"; your dependencies are reduced.
- Reusing your classes will be easier.
- Your classes are less subject to changes in other classes.
- Your code will be easier to test.
- Classes designed this way have been proven to have fewer errors.
Exception 1: Data Structures
Exception 2: The Builder Pattern and Other Fluent APIs
When an API is designed to be fluent (and therefore, usually chained), there’s no good reason to lose the readability just to be a strict Law of Demeter follower. For example, java 8’s Stream API would be worthless if you didn’t allow yourself to chain methods.
http://www.dan-manges.com/blog/37
Models should define business logic and be able to stand alone from views.
http://c2.com/cgi/wiki?LawOfDemeter
Practice
https://medium.com/@orhanobut/yet-again-law-of-demeter-4a7e8fa7707d
private void showAvatar(){
Image image = user.getAccount().getImage();
}
==>
http://blog.csdn.net/vking_wang/article/details/8455636
Exception 2: The Builder Pattern and Other Fluent APIs
When an API is designed to be fluent (and therefore, usually chained), there’s no good reason to lose the readability just to be a strict Law of Demeter follower. For example, java 8’s Stream API would be worthless if you didn’t allow yourself to chain methods.
http://www.dan-manges.com/blog/37
Models should define business logic and be able to stand alone from views.
http://c2.com/cgi/wiki?LawOfDemeter
Practice
https://medium.com/@orhanobut/yet-again-law-of-demeter-4a7e8fa7707d
private void showAvatar(){
Image image = user.getAccount().getImage();
}
==>
| ||
| public Image getAvatar(){ | ||
| if (account == null) { | ||
| return; | ||
| } | ||
| account.getImage(); | ||
| } | ||
| } | ||
| public class Foobar { | ||
| public void showAvatar() { | ||
| Image image = user.getAvatar(); | ||
| } | ||
| } |
又称最少知识原则（Least Knowledge Principle），一个对象应该对其他对象有最少的了解
一个类对自己依赖的类知道的越少越好。也就是说，对于被依赖的类来说，无论逻辑多么复杂，都尽量地的将逻辑封装在类的内部，对外除了提供的public方法，不对外泄漏任何信息。
类与类之间的关系越密切，耦合度越大，当一个类发生改变时，对另一个类的影响也越大。
迪米特法则包含4层含义：
1）只和朋友交流
Only talk to your immediate friends.两个对象之间的耦合就成为朋友关系。即，出现在成员变量、方法输入输出参数中的类就是朋友；局部变量不属于朋友。
--> 不与无关的对象发生耦合！
方针：不要调用从另一个方法中返回的对象中的方法！只应该调用以下方法：
- 该对象本身的方法
- 该对象中的任何组件的方法
- 方法参数中传入的对象的方法
- 方法内部实例化的对象的方法
例如：Teacher类可以命令TeamLeader对Students进行清点，则Teacher无需和Students耦合，只需和TeamLeader耦合即可。
反例：
public float getTemp(){
Thermometer t = station.getThermometer();
return t.getTemp();
}
客户端不应该了解气象站类中的温度计对象；应在气象站类中直接加入获取温度的方法。改为：public float getTemp(){
return station.getTemp();
}
2）朋友间也应该有距离
即使是朋友类之间也不能无话不说，无所不知。
--> 一个类公开的public属性或方法应该尽可能少！
3）是自己的就是自己的
如果一个方法放在本类中也可以、放在其他类中也可以，怎么办？
--> 如果一个方法放在本类中，既不增加类间关系，也对本类不产生负面影响，就放置在本类中。
4）谨慎使用Serializable
否则，若后来修改了属性，序列化时会抛异常NotSerializableException。
建议：
迪米特法则的核心观念是：类间解耦。
其结果是产生了大量中转或跳转类。
