设计原则（5）：迪米特原则

迪米特原则这么说：一个对象应该对其他对象有最少的了解。通俗地讲，一个类应该对自己需要耦 合或调用的类知道得最少，你（被耦合或调用的类）的内部是如何复杂都和我没关系，那是你的事情，我就知 道你提供的这么多public方法，我就调用这么多，其他的我一概不关心。
举个例子：体育老师要求体育委员统计班级的学生总数：





这个例子有一个设计的问题，Teacher类既依赖的Girl类也依赖了GropuLeader类，这与我们的需求是不一致的，理论上Teacher类只需要依赖GropuLeader，然后GropuLeader类依赖Girl类。一似乎我么对其类图进行修改：




这样设计好了以后，就符合迪米特原则了，下面再来一个例子：模拟软件安装的过程：类图如下:




这样设计有一个不合适的点就是，Wizard类把太多的方法暴露给 InstallSoftware类，两者的朋友关系太亲密了，耦合关系变得异常牢固。如果要将Wizard类中的first方法返回值 的类型由int改为boolean，就需要修改InstallSoftware类，从而把修改变更的风险扩散开了。因此，这样的耦合是 极度不合适的，我们需要对设计进行重构，重构后的类图如图5-4所示。



一个类公开的public属性或方法越多，修改时涉及的面也就越大，变更引起的风险扩散也就越大。因此， 为了保持朋友类间的距离，在设计时需要反复衡量：是否还可以再减少public方法和属性，是否可以修改为 private、package-private（包类型，在类、方法、变量前不加访问权限，则默认为包类型）、protected等访问权 限，是否可以加上final关键字等。迪米特法则要求类“羞涩”一点，尽量不要对外公布太多的public方法和非静态的public变量，尽量 内敛，多使用private、package-private、protected等访问权限。