1700455883
}
1700455884
1700455885
}
1700455886
1700455887
在GroupLeader类中定义了一个构造函数，通过构造函数传递了依赖关系。同时，对场景类也进行了一些修改，如代码清单5-7所示。
1700455888
1700455889
代码清单5-7 修改后的场景类
1700455890
1700455891
public class Client{
1700455892
1700455893
public static void main（String[]args）{
1700455894
1700455895
//产生一个女生群体
1700455896
1700455897
List＜Girl＞listGirls=new ArrayList＜Girl＞（）；
1700455898
1700455899
//初始化女生
1700455900
1700455901
for（int i=0；i＜20；i++）{
1700455902
1700455903
listGirls.add（new Girl（））；
1700455904
1700455905
}
1700455906
1700455907
Teacher teacher=new Teacher（）；
1700455908
1700455909
//老师发布命令
1700455910
1700455911
teacher.commond（new GroupLeader（listGirls））；
1700455912
1700455913
}
1700455914
1700455915
}
1700455916
1700455917
对程序进行了简单的修改，把Teacher中对List＜Girl＞的初始化移动到了场景类中，同时在GroupLeader中增加了对Girl的注入，避开了Teacher类对陌生类Girl的访问，降低了系统间的耦合，提高了系统的健壮性。
1700455918
1700455919
注意 一个类只和朋友交流，不与陌生类交流，不要出现getA（）.getB（）.getC（）.getD（）这种情况（在一种极端的情况下允许出现这种访问，即每一个点号后面的返回类型都相同），类与类之间的关系是建立在类间的，而不是方法间，因此一个方法尽量不引入一个类中不存在的对象，当然，JDK API提供的类除外。
1700455920
1700455921
2.朋友间也是有距离的
1700455922
1700455923
人和人之间是有距离的，太远关系逐渐疏远，最终形同陌路；太近就相互刺伤。对朋友关系描述最贴切的故事就是：两只刺猬取暖，太远取不到暖，太近刺伤了对方，必须保持一个既能取暖又不刺伤对方的距离。迪米特法则就是对这个距离进行描述，即使是朋友类之间也不能无话不说，无所不知。
1700455924
1700455925
我们在安装软件的时候，经常会有一个导向动作，第一步是确认是否安装，第二步确认License，再然后选择安装目录……这是一个典型的顺序执行动作，具体到程序中就是：调用一个或多个类，先执行第一个方法，然后是第二个方法，根据返回结果再来看是否可以调用第三个方法，或者第四个方法，等等，其类图如图5-3所示。
1700455926
1700455927
1700455928
1700455929
1700455930
图5-3 软件安装过程类图
1700455931
1700455932
很简单的类图，实现软件安装的过程，其中first方法定义第一步做什么，second方法定义第二步做什么，third方法定义第三步做什么，其实现过程如代码清单5-8所示。