学习设计模式

　　设计模式总共有六大基本原则，统称为SOLID （稳定）原则，分别是S-单一职责原则(Single Responsibility Principle)， O-开闭原则(Open closed Principle)，L-里氏替换原则(Liskov Substitution Principle)，L-迪米特法则(Law of Demeter)，I-接口隔离原则(Interface Segregation Principle)，D-依赖倒置原则(Dependence Invension Principle)。

---

　　

L-迪米特法则(Law of Demeter)

 

一、定义

　　1) Each unit should have only limited knowledge about other units: only units "closely" related to the current unit. (一个类应该对自己需要耦合或调用的类知道的最少)

　　2) Each unit should only talk to its friends; don't talk to strangers.

　　3) Only talk to your immediate friends. (只和直接的朋友通信)

　　来源：https://en.wikipedia.org/wiki/Law_of_Demeter

 

 

 二、理解

　　迪米特法则，也称最少知识原则。一个类应该对自己需要耦合或调用的类知道的最少。通俗地来讲，就是一个类只关心自己调用类提供的方法（通常是public方法)，对其他类的内部实现概不关心。

 　　1) 从调用者的角度考虑，应只和直接的朋友交流。

 　　什么是直接的朋友？即是，内部成员属性、方法的输入输出参数。方法内部的类不算是朋友类。以下代码中GroupLeader是Teacher的直接朋友类，方法内部的List<Girl>不是朋友类。也就是与一个陌生的Girl类交流，这样就破坏了Teacher类的健壮性。

public class Teacher {
　　//老师对学生发布命令,清一下女生
　　public void commond(GroupLeader groupLeader){
　　　　List listGirls = new ArrayList();
　　　　//初始化女生
　　　　for(int i=0;i<20;i++){
　　　　　　listGirls.add(new Girl());
　　　　}
　　　　//告诉体育委员开始执行清查任务
　　　　groupLeader.countGirls(listGirls);
　　}
}

修改代码如下：

public class Teacher {
　　//老师对学生发布命令,清一下女生
　　public void commond(GroupLeader groupLeader){
　　　　//告诉体育委员开始执行清查任务
　　　　groupLeader.countGirls();
　　}
}

修改后的groupleader类 ：

public class GroupLeader {
　　private List<Girl> listGirls;
　　//传递全班的女生进来
　　public GroupLeader(List<Girl> _listGirls){
　　　　this.listGirls = _listGirls;
　　}
　　//清查女生数量
　　public void countGirls(){
　　　　System.out.println("女生数量是:"+this.listGirls.size());
　　}
}

 修改后的场景类：

public class Client {
　　public static void main(String[] args) {
　　　　//产生一个女生群体
　　　　List<Girl> listGirls = new ArrayList<Girl>();
　　　　//初始化女生
　　　　for(int i=0;i<20;i++){
　　　　　　listGirls.add(new Girl());
　　　　}
　　　　Teacher teacher= new Teacher();
　　　　//老师发布命令
　　　　teacher.commond(new GroupLeader(listGirls));
　　}
}

 　　总结，把Teacher类中的List<girl>的初始化，移动到场景类，并在GroupLeader中增加了对Girl的注入，避开了Teacher类对陌生类的访问，降低了系统的耦合性，提高了系统的健壮性。

　　　　 

　　2) 从被调用者的角度考虑，应对外暴露最少的属性或方法，暴露的方法越多，耦合性越强。

　　是自己的，就是自己的。如果一个方法，放在本类中，既不增加类间关系，也不会对本类产生负面影响，就放在本类中

　　迪米特法则要求类“羞涩”一点,尽量不要对外公布太多的public方法和非静态的public变量,尽量内敛,多使用private、package-private、protected等访问权限。

 

 

 三、注意事项

 　　迪米特法则要求类间解耦，但解耦是有限度的。类间解耦，弱耦合了，类的复用率才会高，其要求的结果是产生大量的中间类、跳转类，这样会增加系统的复杂度，同时也会给维护带来难度。所以，需要在两者之前反复权衡，既做到结构清晰，又做到低耦合高内聚。

　　 在实际应用中,如果一个类跳转两次以上才能访问到另一个类,就需要想办法进行重构了,为什么是两次以上呢?因为一个系统的成功不仅仅是一个标准或是原则就能够决定的,有非常多的外在因素决定,跳转次数越多,系统越复杂,维护就越困难,所以只要跳转不超过两次都是可以忍受的,这需要具体问题具体分析。

 

 

学习资料：

　　《设计模式之禅》秦小波 著

　　白话设计——浅谈迪米特法则