迪米特法则也称最少知道原则，虽然名字不同，但描述的是同一个规则:一个对象应该对其他对象有最少的了解。通俗地讲，一个类应该对自己需要耦合或调用的类知道得最少，你(被耦合或调用的类)的内部是如何复杂都和我没关系，那是你的事情，我就知道你提供的这么多public方法，我就调用这么多，其他的我一概不关心。
2.迪米特法则对类的低耦合提出明确的要求4层含义如下:
(1)只和朋友交流迪米特法则还有一个解释是:只与直接的朋友通信。
什么叫直接的朋友?
每个对象都必然会与其他对象有耦合关系，两个对象之间的耦合就成为朋友关系，这种关系的类型有很多，例如组合、聚合、依赖等。
注意:
一个类只和朋友交流，不与陌生类交流，不要出现getA().getB().getC().getD()这种情况(在一种极端的情况下允许出现这种访问，即每个点号后面的返回类型都相同)，类与类之间的关系是建立在类间的，而不是方法间，因此一个方法尽量不引入一个类中不存在的对象，当然，JDK API提供的类例外。
人和人之间是有距离的，太远关系逐渐疏离，最终形同陌路；太近就相互刺伤。对朋友关系描述最贴切的故事就是:两只刺猬取暖，太远取不到温暖，太近刺伤对方，必须保持一个既能取暖又不刺伤对方的距离。迪米特法则就是对这个距离进行描述，即使是朋友类之间也不能无话不说，无所不知。
注意:迪米特法则要求类”羞涩”一点，尽量不要对外公布太多public方法和非静态的public变量，尽量内敛，多使用private、package-private、protected等访问权限。
(3)是自己的就是自己的在实际应用中经常会出现这样一个方法:放在本类中也可以，放在其他类中也没有错，那怎么去衡量呢?你可以坚持这样一个原则:如果一个方法放在本类中，既不增加类间关系，也对本类不产生负面影响，那就放置在本类中。
(4)谨慎使用Serializable 3.最佳实践迪米特法则的核心观念:
类间解耦，弱耦合，只有弱耦合了以后，类的复用率才可以提高。其要求的结果就是:产生了大量的中转或跳转类，导致系统的复杂性提高，同时也为维护带来了难度。所以我们在采用迪米特法则时，需要反复权衡，既做到让结构清晰，又做到高内聚低耦合。
一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。
注意:
开闭原则对扩展开放，对修改关闭，并不意味着不做任何修改，低层模块的变更，必然要有高层模块进行耦合，否则就是一个孤立无意义的代码片段。
变化可以归纳为如下三类:
(1)逻辑变化只变化一个逻辑，而不涉及其他模块，比如原有的一个算法是ab+c，现在需要修改为ab*c，可以通过修改原有类中的方法的方式来完成，前提条件是所有依赖或关联类都按照相同的逻辑处理。
(2)子模块变化一个模块变化，会对其他的模块产生影响，特别是一个低层次的模块变化必然引起高层模块的变化，因此在通过扩展完成变化时，高层次的模块修改是必然的。
(3)可见视图变化可见视图是提供给客户使用的界面，如JSP程序、Swing界面等，该部分的变化一般会引起连锁反应(这个连锁反应，我相信使用过JSP作为视图层的朋友们都深有感触)
2.为什么要采用开闭原则都说开闭原则是非常重要的，可通过以下几个方面来理解其重要性:
(1)开闭原则对测试的影响 (2)开闭原则可以提高复用性 (3)开闭原则可以提高可维护性 (4)面向对象开发的要求 3.如何使用开闭原则 (1)抽象约束抽象是对一组事物的通用描述，没有具体的实现，也就表示它可以由非常多的可能性，可以跟随需求的变化而变化。因此，通过接口或抽象类可以约束一组可能变化的行为，并且能够实现对扩展开放，其包含三层含义:
第一,通过接口或抽象类约束扩展，对扩展进行边界限定，不允许出现在接口或抽象类中不存在的public方法;
第二,参数类型、引用对象尽量使用接口或抽象类，而不是实现类;
第三,抽象层尽量保持稳定，一旦确定即不允许修改;
尽量使用元数据来控制程序的行为，减少重复开放。
什么是元数据?
用来描述环境和数据的数据，通俗地说就是配置参数，参数可以从文件中获得，也可以从数据库中获得。
在一个团队中，建立项目章程是非常重要的，因为章程中指定了所有人员都必须遵守的约定，对项目来说，约定优于配置。
(4)封装变化