贯穿设计模式第六话--迪米特法则

茫茫人海千千万万,感谢这一刻你看到了我的文章,感谢观赏,大家好呀,我是最爱吃鱼罐头,大家可以叫鱼罐头呦~

从今天开始,将开启一个专栏,【贯穿设计模式】,设计模式是对软件设计中普遍存在(反复出现)的各种问题,所提出的解决方案,是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。为了能更好的设计出优雅的代码,为了能更好的提升自己的编程水准,为了能够更好的理解诸多技术的底层源码, 设计模式就是基石,万丈高楼平地起,一砖一瓦皆根基。 ✨✨欢迎订阅本专栏✨✨

本人不才,如果文章知识点有缺漏、错误的地方 ,也欢迎各位人才们评论批评指正!和大家一起学习,一起进步!

❤️ 愿自己还有你在未来的日子,保持学习,保持进步,保持热爱,奔赴山海! ❤️

最后,希望我的这篇文章能对你的有所帮助! 点赞 收藏 ⭐留言 都是我最大的动力!

前言回顾

贯穿设计模式第六话--迪米特法则_第1张图片


​ 【贯穿设计模式】第一话·设计模式初介绍和单一职责原则

​ 【贯穿设计模式】第二话·设计模式的七大原则之开闭原则

​ 【贯穿设计模式】第三话·设计模式的七大原则之依赖倒转

​ 【贯穿设计模式】第四话·设计模式的七大原则之里氏替换

​ 【贯穿设计模式】第五话·设计模式的七大原则之接口隔离

在第五篇文章中,我们了解设计模式的七大原则中第五个原则: 接口隔离原则;

我们来回顾下,它的定义:任一个类不应该依赖它不需要的接口,即一个类对另一个类的依赖应该建立在最少接口上,强调接口的方法尽量少,尽量细化接口。

并且我们通过不同的年级时上的课程是不同的导致接口拥有的职责过多,而且后续增减课程都会造成原有代码的修改。值得注意的是:有时候在实现过程中,不可能将接口中每个方法都隔离出现,毕竟写一个接口就一个方法也不现实,只要表明该接口是处于什么角色,即应该拥有什么职责即可。

迪米特法则

今天我们学习的是迪米特法则,一个实体应当尽量少的与其他实体之间发生相互作用,使得系统功能模块相对独立。迪米特法则又被叫最少知道原则(Least Knowledge Principle)

概述

  • 该法则主要说明一个实体应当尽量少的与其他实体之间发生相互作用,使得系统功能模块相对独立。
  • 迪米特法则主要核心思想就是在于降低类之间的耦合,但需注意的点是由于每个类之间都减少了不必要的依赖,因此迪米特法则只是要求降低类之间(对象间)耦合关系,并不是要求完全没有依赖关系;
  • 简单理解一个类应当尽量减少对其他类的依赖,即类和类直接应该建立在最小的依赖之上,一个类应该对其依赖的类有最小的了解,即只需要知道其所需要的方法即可,至于其内部具体是如何实现的则不用关心;
  • 比如有三个类A、B、C,现在A类只需要调用B类的方法,B类则去调用C类的属性,如果此时A类中出现了C类的对象,就相当于A类和C类发生了耦合关系,但实际上两者并不相关,并没有联系。此时B类应该完成处理C类的属性以及方法再将结果返回给A类,而A类也不需要出现C类即可,也就是迪米特法则即最少知道原则。

迪米特法则还有一个简单的定义:不要和陌生人说话,只与直接的朋友通信。对于出现在成员变量、方法的输入和输出参数中的类都可以被称为直接朋友,而出现在方法体内部的类不属于朋友类即陌生人。

在应用迪米特法则时,一个对象只能与直接朋友发生交互,不要与陌生人发生直接交互,这样做可以降低系统的耦合度,一个对象的改变不会给太多其他对象带来影响。

☘️特点

迪米特法则的核心就是降低类之间的耦合,减少暴露类成员,降低对类的访问权限。如果遵循迪米特法则将有以下优点

  • 降低了类之间的耦合度,使类与类之间保持松散的耦合关系;
  • 由于耦合度降低,提高了模块的相对独立性;
  • 提高类的可复用性和系统的扩展性。

问题引出

贯穿设计模式第六话--迪米特法则_第2张图片

还记得上学时候最舒服的时候就是放寒暑假的时候,直接满满两个月的假期,但本人虽宅,也还是非常期待这种两个月睡到中午的感觉,这感觉自从上班后,就再也没怎么幸福了哈哈。虽然说放假很快乐,但是每次放假都是超级多作业要做,而且每次都拖到上学前一两天的时候,所以每次放假最后两天都是个人最忙的时候,不知道你是否也是一样呢哈哈,但是学霸、学神的你,自然不会的啦!
随着放假结束,但是总也有作业没抄完,自然会特别期待老师不要交作业,但总是事与愿违。这不,放假后第一天上学,最可怕的声音出现了,“ 请班长收下各科暑假作业,今天放学前放在我办公室的桌子上,没写的同学,统计一下,明天叫下家长。 ”那接下来我们以老师叫班长收学生的作业来讲解下迪米特法则吧。

1. 先创建个学生类Student:

既然要收作业,得有学生才能收吧~

package com.ygt.principle.lod;

/**
 * 创建一个学生类,这样才能收学生作业啦
 *  可以不写任何属性在里面,直接计算收了多少名学生作业即可啦!
 */
public class Student {

}

2. 创建班长类Monitor,收作业的方法:

package com.ygt.principle.lod;

import java.util.List;

/**
 * 班长类,去收集学生作业
 */
public class Monitor {

    // 收集作业后,统计给老师多少份
    public void collectHomework(List<Student> students){
        System.out.println("收集了" + students.size() + "份作业,请老师查收!");
    }
}

3. 创建老师类Teacher,叫班长去收作业的方法:

package com.ygt.principle.lod;

import java.util.ArrayList;
import java.util.List;

/**
 * 老师类,叫班长收集学生作业,并统计给我
 */
public class Teacher {

    // 叫班长收集作业
    public void callMonitorToHomeWork(Monitor monitor){
        // 初始化学生
        List<Student> studentList = new ArrayList<>();
        for (int i = 0; i < 15; i++) {
            studentList.add(new Student());
        }

        // 叫班长收作业
        monitor.collectHomework(studentList);
    }
}

4. 创建测试类,测试老师叫班长收学生作业的流程:

package com.ygt.principle.lod;

/**
 * 迪米特法则的测试类
 */
public class LawOfDemeteTest {
    public static void main(String[] args) {
        // 初始化老师和班长
        Teacher teacher = new Teacher();
        Monitor monitor = new Monitor();

        teacher.callMonitorToHomeWork(monitor);
    }
}

5. 得到的结果:

收集了15份作业,请老师查收!

贯穿设计模式第六话--迪米特法则_第3张图片

这份代码,乍一看,没什么问题,但是你仔细观察,Teacher类中callMonitorToHomeWork()不怎么对劲呀,我明明是让Monitor去收作业,这作业还没先收到,为啥Student出现在方法了呢,而且Student类并不是Teacher类的直接朋友,而是“ 陌生人 ”,这就违反了迪米特法则,但这改正也特别的简单,只需要将Student类抽出在方法外即可,那具体怎么做呢?接下来就一起看看解决方案吧!

解决方案

在迪米特法则中,我们知道不要和陌生人说话,只与直接的朋友通信,所以我们只需要去调用Monitor类中collectHomework方法即可,而Student类不要出现在Teacher类,出现在Monitor类中即可。

1. 修改Monitor类:

既然要收作业,得有学生才能收吧~

package com.ygt.principle.lod;

import java.util.ArrayList;
import java.util.List;

/**
 * 班长类,去收集学生作业
 */
public class Monitor {

    private List<Student> studentList;

    public Monitor(List<Student> studentList) {
        this.studentList = studentList;
    }

    // 收集作业后,统计给老师多少份
    public void collectHomework(){
        // 班长直接报告收到多少作业即可。
        System.out.println("收集了" + studentList.size() + "份作业,请老师查收!");
    }
}

2. 修改Teacher类:

package com.ygt.principle.lod;

/**
 * 老师类,叫班长收集学生作业,并统计给我
 */
public class Teacher {

    // 叫班长收集作业
    public void callMonitorToHomeWork(Monitor monitor){

        // 学生类不要出现Teacher类中。
        // 叫班长收作业
        monitor.collectHomework();
    }
}

3. 修改测试类,重新测试老师叫班长收作业过程:

package com.ygt.principle.lod;

import java.util.ArrayList;
import java.util.List;

/**
 * 迪米特法则的测试类
 */
public class LawOfDemeteTest {
    public static void main(String[] args) {
        // 初始化老师和班长
        Teacher teacher = new Teacher();

        // 初始化学生
        List<Student> studentList = new ArrayList<>();
        for (int i = 0; i < 15; i++) {
            studentList.add(new Student());
        }
        Monitor monitor = new Monitor(studentList);


        teacher.callMonitorToHomeWork(monitor);
    }
}

4. 得到的结果:

收集了15份作业,请老师查收!

贯穿设计模式第六话--迪米特法则_第4张图片

这样我们将Teacher类中出现的 “ 陌生人 ”Student 类抽离出现,把Teacher中对List的初始化移动到了测试类中,同时在Monitor中增加了对Student的注入,避开了Teacher类对陌生类Student的访问,降低了系统间的耦合,提高了系统的健壮性,也实现了迪米特法则啦。

在应用迪米特法则时,我们只需要知道一个对象只能与直接朋友发生交互,不要与陌生人发生直接交互,这样做可以降低系统的耦合度,所以一个方法尽量不引入一个类中不存在的对象。

完结

相信各位看官看到这里大致都对设计模式中的其中一个原则有了了解吧,迪米特法则指一个实体应当尽量少的与其他实体之间发生相互作用,使得系统功能模块相对独立,要求降低类之间(对象间)耦合关系,并不是要求完全没有依赖关系。

学好设计模式,让你感受一些机械化代码之外的程序设计魅力,也可以让你理解各个框架底层的实现原理。最后,祝大家跟自己能在程序员这条越走越远呀,祝大家人均架构师,我也在努力。 接下来期待第七话:合成复用原则。

文章的最后来个小小的思维导图:

贯穿设计模式第六话--迪米特法则_第5张图片

本人不才,如有什么缺漏、错误的地方,也欢迎各位人才们评论批评指正!

当然如果这篇文章确定对你有点小小帮助的话,也请亲切可爱的人才们给个点赞、收藏下吧,非常感谢!

虽然这篇文章完结了,但是我还在,永不完结。我会努力保持写文章。来日方长,何惧车遥马慢!✨✨✨

感谢各位看到这里!愿你韶华不负,青春无悔!让我们一起加油吧!

学到这里,今天的世界打烊了,晚安!

你可能感兴趣的:(贯穿设计模式,设计模式,接口隔离原则,java)