越级上报不可行,各司其职才是王道---迪米特法则
前言
- 迪米特法则要求类与类之间应该尽量减少互相的了解。别名又称最少知识原则
- 相信搞Java的同学一听肯定会说这不就是低耦合吗。
- 只要两个类有耦合关系,我们就称两个类为直接朋友关系。迪米特法则要求类只与直接朋友交流。那么我们如何界定类与类之间的耦合关系呢
- 上述三种关系我们就称之为耦合关系或者说是直接朋友关系。这里需要注意的是仅出现在方法内部的类并不是直接朋友。
代码场景
- 话不多说,我们直接上代码吧。
public class Demeter {
public static void main(String[] args) {
new SchoolManager().printAllEmployers(new CollegeManager());
}
}
class Employer{
private String id;
public String getId() {
return id;
}
public void setId(String id) {
this.id = id;
}
@Override
public String toString() {
return "collge:"+this.id;
}
}
class CollegeEmployer{
private String id;
public String getId() {
return id;
}
public void setId(String id) {
this.id = id;
}
@Override
public String toString() {
return "school:"+this.id;
}
}
class SchoolManager{
public List<Employer> schoolAllEmployers() {
List<Employer> list = new ArrayList<>();
for (int i = 0; i < 10; i++) {
Employer employer = new Employer();
employer.setId(String.valueOf(i));
list.add(employer);
}
return list;
}
public void printAllEmployers(CollegeManager manager) {
/*System.out.println(Arrays.toString(manager.collegeAllEmployers().toArray()));
System.out.println(Arrays.toString(schoolAllEmployers().toArray()));*/
for (CollegeEmployer collegeAllEmployer : manager.collegeAllEmployers()) {
System.out.println(collegeAllEmployer.getId());
}
for (Employer schoolAllEmployer : schoolAllEmployers()) {
System.out.println(schoolAllEmployer.getId());
}
}
}
class CollegeManager{
public List<CollegeEmployer> collegeAllEmployers() {
List<CollegeEmployer> list = new ArrayList<>();
for (int i = 0; i < 10; i++) {
CollegeEmployer collegeEmployer = new CollegeEmployer();
collegeEmployer.setId(String.valueOf(i));
list.add(collegeEmployer);
}
return list;
}
}
- 上面的功能就是打印两个部门的成员数据。但是对于
SchoolManager
来说在打印成员变量的时候居然使用到CollegeEmployer
这个非直接朋友。那么他就直接打破了迪米特法则。 - 但是不管我们怎么消除耦合,耦合是肯定会存在的。我们只能从职责上将各个类的功能界定好。比如说上面的
CollegeEmployer
的打印逻辑就不应该放在SchoolManager
中。 - 就好比领兵打仗,皇帝只需要派大将军过去指挥将士们。将士们是如何杀敌的过程不需要和皇帝沟通。皇帝只需要也只想看到结果。
SchoolManager
也是我只想打印成员,具体怎么打印不要告诉我,也不要让我操心。所以解决迪米特法则的冲突也很简单。我们只需要将冲突点上提即可。
总结
- 无规矩不成方圆。仔细回想下我们之前的代码开发,肯定很多都是破坏了迪米特法则。设计模式的难点就在于你可以不尊从他的原则照样可以开发出程序甚至可以稳定运行。但是无法面对后期的需求车轮战。
- 但是如果从一开始我们就尽量遵从设计原则的话,那么在后期需求的扩张时,我们能够将我们的代码有序的进行升级而不破坏已有的功能。或者说我们能够一直按照一定的设计进行开发。
\
转载自:https://juejin.cn/post/7094055999874695199