01.问题思考的分析什么是迪米特原则这个原则如何理解如何运用到实际开发举例说明一下什么是高内聚松耦合能否举例说明一下迪米特法则。尽管它不像 SOLID、KISS、DRY 原则那样人尽皆知但它却非常实用。利用这个原则能够帮我们实现代码的“高内聚、松耦合”。今天就围绕下面几个问题并结合两个代码实战案例来深入地学习这个法则。什么是“高内聚、松耦合”如何利用迪米特法则来实现“高内聚、松耦合”有哪些代码设计是明显违背迪米特法则的对此又该如何重构02.学习迪米特原则目标迪米特原则Law of Demeter也被称为最少知识原则Principle of Least Knowledge是面向对象设计中的一个重要原则。能够清晰知道该原则的思想并且可以应用到实际代码中学习的目标是降低类之间的耦合性提高代码的可维护性和可扩展性。03.理解迪米特原则3.1 迪米特原则介绍迪米特法则的英文翻译是Law of Demeter缩写是 LOD。不过它还有另外一个更加达意的名字叫作最小知识原则英文翻译为The Least Knowledge Principle。关于这个设计原则我们先来看一下它最原汁原味的英文定义Each unit should have only limited knowledge about other units: only units “closely” related to the current unit. Or: Each unit should only talk to its friends; Don’t talk to strangers.把它直译成中文 每个模块unit只应该了解那些与它关系密切的模块units: only units “closely” related to the current unit的有限知识knowledge。或者说每个模块只和自己的朋友“说话”talk不和陌生人“说话”talk。3.2 迪米特原则由来类与类之间的关系越密切耦合度越大当一个类发生改变时对另一个类的影响也越大。这个时候要降低类之间耦合3.3 内聚和耦合关系“高内聚”有助于“松耦合”同理“低内聚”也会导致“紧耦合”。类的粒度比较小每个类的职责都比较单一。相近的功能都放到了一个类中不相近的功能被分割到了多个类中。这样类更加独立代码的内聚性更好。因为职责单一所以每个类被依赖的类就会比较少代码低耦合。一个类的修改只会影响到一个依赖类的代码改动。我们只需要测试这一个依赖类是否还能正常工作就行了。类粒度比较大低内聚功能大而全不相近的功能放到了一个类中。这就导致很多其他类都依赖这个类。当我们修改这个类的某一个功能代码的时候会影响依赖它的多个类。这也就是所谓的“牵一发而动全身”。3.3 何为高内聚松耦合“高内聚、松耦合”是一个非常重要的设计思想。能够有效地提高代码的可读性和可维护性缩小功能改动导致的代码改动范围。很多设计原则都以实现代码的“高内聚、松耦合”为目的比如单一职责原则、基于接口而非实现编程等。在这个设计思想中“高内聚”用来指导类本身的设计“松耦合”用来指导类与类之间依赖关系的设计。所谓高内聚就是指相近的功能应该放到同一个类中不相近的功能不要放到同一个类中。相近的功能往往会被同时修改放到同一个类中修改会比较集中代码容易维护。所谓松耦合是说在代码中类与类之间的依赖关系简单清晰。即使两个类有依赖关系一个类的代码改动不会或者很少导致依赖类的代码改动。04.迪米特原则思想迪米特原则的核心观念 : 就是类之间的解耦解耦是有一定程度的尽量做到弱耦合耦合程度越低类的复用率才能提高。由于减少了类之间不必要的依赖从而达到了降低了耦合的目的。迪米特法则的原理是通过封装和信息隐藏来实现对象之间的松耦合。每个对象只需要知道与之直接交互的对象的接口而不需要了解对象的内部实现细节。05.迪米特原则案例1例子有一个集团公司下属单位有分公司和直属部门现在要求打印出所有下属单位的员工ID。先来看一下违反迪米特法则的设计。// 总公司员工 class Employee { private String id; public String getId() { return id; } public void setId(String id) { this.id id; } } // 分公司员工 class SubEmployee { private String id; public String getId() { return id; } public void setId(String id) { this.id id; } } // 子公司管理 class SubCompanyManager { public ListSubEmployee getAllEmployee() { ListSubEmployee list new ArrayList(); for (int i 1; i 5; i) { SubEmployee subEmployee new SubEmployee(); // 给分公司人员顺序分配一个ID subEmployee.setId(分公司 i); list.add(subEmployee); } return list; } } // 总公司管理 class CompanyManager { public ListEmployee getAllEmployee() { ListEmployee list new ArrayList(); for (int i 1; i 3; i) { Employee employee new Employee(); // 给总公司人员顺序分配一个ID employee.setId(总公司 i); list.add(employee); } return list; } public void printAllEmployee(SubCompanyManager subCompanyManager) { // 分公司员工 ListSubEmployee subEmployeeList subCompanyManager.getAllEmployee(); for (SubEmployee subEmployee : subEmployeeList) { System.out.println(subEmployee.getId()); } // 总公司员工 ListEmployee employeeList getAllEmployee(); for (Employee employee : employeeList) { System.out.println(employee.getId()); } } }问题出现在CompanyManager类根据迪米特法则只与直接的朋友发生通信。而SubEmployee类并不是CompanyManager类的直接朋友以局部变量出现的耦合不属于直接朋友从逻辑上讲总公司只与他的分公司耦合就行了与分公司的员工并没有任何联系这样设计显然是增加了不必要的耦合。按照迪米特法则应该避免类中出现这样非直接朋友关系的耦合。修改后的代码如下// 总公司员工 class Employee { private String id; public String getId() { return id; } public void setId(String id) { this.id id; } } // 分公司员工 class SubEmployee { private String id; public String getId() { return id; } public void setId(String id) { this.id id; } } // 子公司管理 class SubCompanyManager { public ListSubEmployee getAllEmployee() { ListSubEmployee list new ArrayList(); for (int i 1; i 5; i) { SubEmployee subEmployee new SubEmployee(); // 给分公司人员顺序分配一个ID subEmployee.setId(分公司 i); list.add(subEmployee); } return list; } public void printSubCompany() { ListSubEmployee subEmployeeList this.getAllEmployee(); for (SubEmployee subEmployee : subEmployeeList) { System.out.println(subEmployee.getId()); } } } // 总公司管理 class CompanyManager { public ListEmployee getAllEmployee() { ListEmployee list new ArrayList(); for (int i 1; i 3; i) { Employee employee new Employee(); // 给总公司人员顺序分配一个ID employee.setId(总公司 i); list.add(employee); } return list; } public void printAllEmployee(SubCompanyManager subCompanyManager) { // 分公司员工 subCompanyManager.printSubCompany(); // 总公司员工 ListEmployee employeeList getAllEmployee(); for (Employee employee : employeeList) { System.out.println(employee.getId()); } } } public class Client { public static void main(String[] args) { CompanyManager companyManager new CompanyManager(); companyManager.printAllEmployee(new SubCompanyManager()); } }修改后为分公司增加了打印人员ID的方法总公司直接调用来打印从而避免了与分公司的员工发生耦合。06.迪米特原则案例2上体育课我们经常有这样一个场景体育老师上课前要体育委员确认一下全班女生到了多少位也就是体育委员清点女生的人数。public class Teacher{ //老师对体育委员发一个命令让其清点女生人数 public void command(GroupLeader groupLeader){ ListGirl listGirls new ArrayList(); //初始化女生 for(int i0;i20;i){ listGirls.add(new Girl()); } //告诉体育委员开始清点女生人数 groupLeader.countGirls(listGirls); } } public class GroupLeader{ //清点女生数量 public void countGirls(ListGirl listGirls){ System.out.println(女生人数是listGirls.size()); } } publci class Girl{ } public class Client{ public static void main(Strings[] args){ Teacher teacher new Teacher(); //老师给体育委员发清点女生人数的命令 teacher.command(new GroupLeader()); } }我们再回头看Teacher类Teacher类只有一个朋友类GroupLeaderGirl类不是朋友类但是Teacher与Girl类通信了这就破坏了Teacher类的健壮性Teacher类的方法竟然与一个不是自己的朋友类Girl类通信这是不允许的严重违反了迪米特原则。public class Teacher{ //老师对体育委员发一个命令让其清点女生人数 public void command(GroupLeader groupLeader){ //告诉体育委员开始清点女生人数 groupLeader.countGirls(); } } public class GroupLeader{ private ListGirl listGirls; public GroupLeader(ListGirl listGirls){ this.listGirls listGirls; } //清点女生数量 public void countGirls(){ System.out.println(女生人数是listGirls.size()); } } public class Client{ public static void main(Strings[] args){ //产生女生群体 ListGirl listGirls new ArrayListGirl(); //初始化女生 for(int i0;i20;i){ listGirls.add(new Girl()); } Teacher teacher new Teacher(); //老师给体育委员发清点女生人数的命令 teacher.command(new GroupLeader(listGirls)); } }对程序修改把Teacher中对Girl群体的初始化移动到场景类中同时在GroupLeader中增加对Girl的注入避开了Teacher类对陌生类Girl的访问降低了系统间的耦合提高了系统的健壮性。07.迪米特原则思考7.1 迪米特原则要点降低耦合性迪米特原则鼓励将关注点分离使得类之间的依赖关系尽可能松散。一个类应该尽量减少对其他类的直接依赖而是通过中间类或接口进行通信。提高模块独立性迪米特原则鼓励将系统划分为独立的模块每个模块只与其直接的朋友直接依赖的类进行通信。使得模块更加独立修改一个模块不会对其他模块造成影响提高了系统的可扩展性和可重用性。保护隐私信息迪米特原则要求一个对象只与其直接的朋友进行通信不要暴露过多的内部信息给外部对象。这样可以保护对象的隐私信息减少不必要的依赖和耦合。提高代码的可维护性通过遵循迪米特原则代码的结构更加清晰类之间的关系更加简单明了。这使得代码更易于理解、调试和修改提高了代码的可维护性。不该有直接依赖关系的类之间不要有依赖有依赖关系的类之间尽量只依赖必要的接口。迪米特法则是希望减少类之间的耦合让类越独立越好。每个类都应该少了解系统的其他部分。一旦发生变化需要了解这一变化的类就会比较少。7.2 迪米特原则优缺点优点降低类之间的耦合度提高了模块的相对独立性耦合度降低从而提高了类的可重用率和系统的扩展性缺点过度使用迪米特原则会产生大量的中介类导致系统的复杂度提高。在釆用迪米特法则时需要反复权衡确保高内聚和低耦合的同时保证系统的结构清晰。7.3 迪米特设计体现广义的迪米特法则在类的设计上的体现优先考虑将一个类设置成不变类。尽量降低一个类的访问权限。谨慎使用Serializable。尽量降低成员的访问权限。7.4 思考迪米特原则场景有几个设计模式在实现中使用了迪米特原则包括通过提供一个简化的接口将复杂子系统的接口与客户端解耦符合迪米特原则的要求使得客户端不需要了解子系统的内部细节。通过引入一个中介者对象将多个对象之间的通信集中处理减少对象之间的直接交互符合迪米特原则的要求。通过提供一个统一的迭代接口隐藏集合对象的内部结构使得客户端不需要了解集合的具体实现细节符合迪米特原则的要求。这些设计模式都通过减少对象之间的直接依赖关系showWEIBO.COM/ttarticle/p/show?id2309405283388197306601降低耦合度提高系统的可维护性和灵活性从而符合迪米特原则的设计原则。