java设计模式七大原则之迪米特原则详解

目录
  • 1.什么是迪米特原则?
  • 2.违反迪米特原则代码案例
  • 3.遵守迪米特原则代码案例
  • 4.迪米特原则的注意事项

1.什么是迪米特原则?

一个对象应该对其他对象保持最少的了解。

类与类关系越密切,耦合度越大。

迪米特法则(Demeter Principle)又叫最少知道原则,即一个类对自己依赖的类知道的越少越好。也就是说,对于被依赖的类不管多么复杂,都尽量将逻辑封装在类的内部。对外除了提供的public方法,不对外泄露任何信息。

迪米特法则还有个更简单的定义:只与直接的朋友通信。

直接的朋友:每个对象都会与其他对象有耦合关系,只要两个对象之间有耦合关系,我们就说这两个对象之间是朋友关系。耦合的方式很多,依赖,关联,组合,聚合等。其中,我们称出现成员变量,方法参数,方法返回值中的类为直接的朋友,而出现在局部变量中的类不是直接的朋友。也就是说,陌生的类最好不要以局部变量的形式出现在类的内部。

2.违反迪米特原则代码案例

代码中的注释我已经写的很详细了,大家有问题即可指出。

package com.szh.principle.demeter;
import java.util.ArrayList;
import java.util.List;
/**
 *
 */
//学校总部员工类
class Employee {
    private String id;
    public void setId(String id) {
        this.id = id;
    }
    public String getId() {
        return id;
    }
}
//学院的员工类
class CollegeEmployee {
    private String id;
    public void setId(String id) {
        this.id = id;
    }
    public String getId() {
        return id;
    }
}
//管理学院员工的管理类
class CollegeManager {
    //返回学院的所有员工
    public List<CollegeEmployee> getAllEmployee() {
        List<CollegeEmployee> list = new ArrayList<>();
        for (int i = 1; i <= 5; i++) { //这里我们增加了5个员工到 list
            CollegeEmployee emp = new CollegeEmployee();
            emp.setId("学院员工id= " + i);
            list.add(emp);
        }
        return list;
    }
}
//学校管理类
//分析 SchoolManager 类的直接朋友类有哪些: Employee、CollegeManager
//CollegeEmployee 不是 直接朋友, 而是一个陌生类, 这样违背了 迪米特法则
class SchoolManager {
    //返回学校总部的员工
    public List<Employee> getAllEmployee() {
        List<Employee> list = new ArrayList<>();
        for (int i = 1; i <=3 ; i++) { //这里我们增加了3个员工到 list
            Employee emp = new Employee();
            emp.setId("学校总部员工id= " + i);
            list.add(emp);
        }
        return list;
    }
    //该方法完成输出学校总部和学院员工信息(id)
    void printAllEmployee(CollegeManager sub) {
        //分析问题
        //1. 这里的 CollegeEmployee 不是 SchoolManager 的直接朋友
        //2. CollegeEmployee 是以局部变量方式出现在 SchoolManager
        //3. 违反了 迪米特法则
        //获取到学院员工
        List<CollegeEmployee> list1 = sub.getAllEmployee();
        System.out.println("------------学院员工------------");
        list1.stream().map(CollegeEmployee::getId).forEach(System.out::println);
        //获取到学校总部员工
        List<Employee> list2 = this.getAllEmployee();
        System.out.println("------------学校总部员工------------");
        list2.stream().map(Employee::getId).forEach(System.out::println);
    }
}
public class Demeter {
    public static void main(String[] args) {
        //创建了一个 SchoolManager 对象
        SchoolManager schoolManager = new SchoolManager();
        //输出学院的员工id 和 学校总部的员工信息
        schoolManager.printAllEmployee(new CollegeManager());
    }
}

3.遵守迪米特原则代码案例

前面设计的问题在于SchoolManager 中,CollegeEmployee 类并不是SchoolManager类的直接朋友。

按照迪米特法则,应该避免类中出现这样非直接朋友关系的耦合。我们将上面的代码进行修改,使其遵守迪米特原则。

package com.szh.principle.demeter.improve;
import java.util.ArrayList;
import java.util.List;
/**
 *
 */
//学校总部员工类
class Employee {
    private String id;
    public void setId(String id) {
        this.id = id;
    }
    public String getId() {
        return id;
    }
}
//学院的员工类
class CollegeEmployee {
    private String id;
    public void setId(String id) {
        this.id = id;
    }
    public String getId() {
        return id;
    }
}
//管理学院员工的管理类
class CollegeManager {
    //返回学院的所有员工
    public List<CollegeEmployee> getAllEmployee() {
        List<CollegeEmployee> list = new ArrayList<>();
        for (int i = 1; i <= 5; i++) { //这里我们增加了5个员工到 list
            CollegeEmployee emp = new CollegeEmployee();
            emp.setId("学院员工id= " + i);
            list.add(emp);
        }
        return list;
    }
    //输出学院员工的信息
    public void printEmployee() {
        //获取到学院员工
        List<CollegeEmployee> list1 = getAllEmployee();
        System.out.println("------------学院员工------------");
        list1.stream().map(CollegeEmployee::getId).forEach(System.out::println);
    }
}
//学校管理类
//分析 SchoolManager 类的直接朋友类有哪些: Employee、CollegeManager
//CollegeEmployee 不是 直接朋友, 而是一个陌生类, 这样违背了 迪米特法则
class SchoolManager {
    //返回学校总部的员工
    public List<Employee> getAllEmployee() {
        List<Employee> list = new ArrayList<>();
        for (int i = 1; i <= 3; i++) { //这里我们增加了3个员工到 list
            Employee emp = new Employee();
            emp.setId("学校总部员工id= " + i);
            list.add(emp);
        }
        return list;
    }
    //该方法完成输出学校总部和学院员工信息(id)
    void printAllEmployee(CollegeManager sub) {
        //分析问题
        //改进代码:将输出学院的员工方法,封装到CollegeManager
        sub.printEmployee();
        //获取到学校总部员工
        List<Employee> list2 = getAllEmployee();
        System.out.println("------------学校总部员工------------");
        list2.stream().map(Employee::getId).forEach(System.out::println);
    }
}
public class Demeter {
    public static void main(String[] args) {
        System.out.println("~~~使用迪米特法则的改进~~~");
        //创建了一个 SchoolManager 对象
        SchoolManager schoolManager = new SchoolManager();
        //输出学院的员工id 和  学校总部的员工信息
        schoolManager.printAllEmployee(new CollegeManager());
    }
}

4.迪米特原则的注意事项

迪米特法则的核心是降低类之间的耦合。

但是注意:由于每个类都减少了不必要的依赖,因此迪米特法则只是要求降低类间(对象间)耦合关系,并不是要求完全没有依赖关系。

以上就是java设计模式七大原则之迪米特原则详解的详细内容,更多关于java设计模式迪米特原则的资料请关注我们其它相关文章!

(0)

相关推荐

  • java设计模式七大原则之依赖倒转原则详解

    目录 1.什么是依赖倒转原则? 2.代码案例 3.依赖关系传递的三种方式和案例举例 3.1 接口传递 3.2 构造方法传递 3.3 setter方法传递 4.依赖倒转原则总结 1.什么是依赖倒转原则? 高层模块不应该依赖低层模块,二者都应该依赖其抽象. 抽象不应该依赖细节,细节应该依赖抽象. 依赖倒转 (倒置) 的中心思想是面向接口编程. 依赖倒转原则是基于这样的设计理念:相对于细节的多变性,抽象的东西要稳定的多.以抽象为基础搭建的架构比以细节为基础的架构要稳定的多.在Java中,抽象指的是接口

  • Java设计模式七大原则之迪米特法则详解

    目录 定义 案例 需求 方案一 方案二 对比分析 总结 定义 迪米特法则(Law of Demeter, LoD)是1987年秋天由lan holland在美国东北大学一个叫做迪米特的项 目设计提 出的,它要求一个对象应该对其他对象有最少的了解,所以迪米特法则又叫做最少知识原则. 案例 需求 有一个公司,下属有各个部门,现要求打印出公司员工的ID和部门员工的ID 方案一 定义公司员工类 /** * 公司员工 * @author:liyajie * @createTime:2022/2/8 11:

  • 从汇编代码开始全面解析synchronized还原最真实的偏向锁

    目录 前言 一.TemplateTable::monitorenter() 二.lock_object(): 三.biased_locking_enter() 1).参数 2).概念 3).源码 前言 我们都知道java之所以跨平台能力强,是因为java在编译期没有被编译成机器码,而是被编译成字节码.早期的jvm会将编译好的字节码翻译成机器码解释执行,我们在jvm的源码中还可以看到早期的解释器——bytecodeInterpreter.cpp(虽然已经不再使用).对于字节码这种总数固定,解释逻辑

  • 示例解析java设计模式七大原则接口隔离原则及优化

    目录 1.什么是接口隔离原则? 2.对应代码 3.改进代码 4.接口隔离原则总结 1.什么是接口隔离原则? 客户端不应该依赖它不需要的接口,即一个类对另一个类的依赖应该建立在最小的接口范围上. 2.对应代码 上面这张图呢,就违反了接口隔离原则.它对应的代码如下: package com.szh.principle.segregation; /** * */ interface Interface1 { void operation1(); void operation2(); void oper

  • nacos客户端一致性hash负载需求实现

    目录 1.首先创建NacosClient,监听对应的服务: 2.创建Nodelistener,主要处理构建hash环等逻辑: 3.负载均衡器: 思考: 最近接到一个需求,由于文件服务器上传文件后,不同节点之间共享文件需要延迟,上游上传文件后立刻去下载,如果负载到其他节点上可能会找不到文件,所以使用文件服务器接入nacos根据相同的trace_id路由到一个节点上,这样保证上传后立刻下载的请求都能路由到同一个节点上,研究了两天nacos原生的client发现并没有提供相关功能,于是便产生了一个想法

  • java设计模式七大原则之开闭原则示例详解

    目录 1.什么是开闭原则? 2.违反Ocp代码案例 3.遵守Ocp代码案例 1.什么是开闭原则? 开闭原则(Open Closed Principle)是编程中最基础.最重要的设计原则.一个软件实体如类,模块和函数应该对扩展开放(对提供方),对修改关闭(对使用方).用抽象构建框架,用实现扩展细节.当软件需要变化时,尽量通过扩展软件实体的行为来实现变化,而不是通过修改已有的代码来实现变化.编程中遵循其它原则,以及使用设计模式的目的就是遵循开闭原则. 2.违反Ocp代码案例 package com.

  • Java 设计模式原则之迪米特法则详解

    定义 一个对象应该对其他对象保持最少的了解. 问题由来 类与类之间的关系越密切,耦合度越大,当一个类发生改变时,对另一个类的影响也越大. 解决方案 尽量降低类与类之间的耦合. 自从我们接触编程开始,就知道了软件编程的总的原则:低耦合,高内聚.无论是面向过程编程还是面向对象编程,只有使各个模块之间的耦合尽量的低,才能提高代码的复用率.低耦合的优点不言而喻,但是怎么样编程才能做到低耦合呢?那正是迪米特法则要去完成的. 迪米特法则又叫最少知道原则,最早是在1987年由美国Northeastern Un

  • Java设计模式之责任链模式的示例详解

    目录 应用场景 实际代码案例 无模式情况下的代码 采用责任链模式优化代码 采用建造者+责任链模式优化代码 责任链模式优缺点 责任链模式是将链中的每一个节点看做是一个对象,每个节点处理的请求均不相同,且内部自动维护下一个节点对象,当一个请求从链式的首段发出时,会沿着链的路径依次传递给每一个节点对象,直至有对象处理这个请求位置,属于行为模式. 这里需要注意的是每个节点都能对对象进行一定的处理(也可以不处理),处理完成之后节点再进行判断还要进行后续处理还是说传递给下一个节点. 应用场景 首先举一个日常

  • Java设计模式之装饰模式原理与用法实例详解

    本文实例讲述了Java设计模式之装饰模式原理与用法.分享给大家供大家参考,具体如下: 装饰模式能在不必改变原类文件和使用继承的情况下,动态地扩展一个对象的功能.它是通过创建一个包装对象,也就是装饰来包裹真实的对象.JDK中IO的设计就用到了装饰模式,通过过滤流对节点流进行包装来实现功能的扩展. 装饰模式的角色的组成: ① 抽象构件(Component)角色:给出一个抽象接口,以规范准备接收附加工功能的对象.(InputStream.OutputStream) ② 具体构件(Concrete Co

  • Java设计模式之策略模式定义与用法详解

    本文实例讲述了Java策略模式定义与用法.分享给大家供大家参考,具体如下: 一. 定义: 定义一系列算法,把他们一个一个封装起来,并且使他们可以相互替换. 二. 优点: (1)上下文(Context)和具体策略(ConcreteStrategy)是松耦合关系,因此上下文只需要知道他要使用某一个实现  Strategy接口类的实例,但不需要知道是哪个类. (2)策略模式满足开闭原则,当增加新的具体类时,不需要修改上下文类的代码,上下文即可以引用新的具体策略的实例. 三. 实例: 下面就通过一个问题

  • 理解Java设计模式编程中的迪米特原则

    定义:一个对象应该对其他对象保持最少的了解. 问题由来:类与类之间的关系越密切,耦合度越大,当一个类发生改变时,对另一个类的影响也越大. 解决方案:尽量降低类与类之间的耦合.          自从我们接触编程开始,就知道了软件编程的总的原则:低耦合,高内聚.无论是面向过程编程还是面向对象编程,只有使各个模块之间的耦合尽量的低,才能提高代码的复用率.低耦合的优点不言而喻,但是怎么样编程才能做到低耦合呢?那正是迪米特法则要去完成的.          迪米特法则又叫最少知道原则,最早是在1987年

  • JAVA设计模式之访问者模式原理与用法详解

    本文实例讲述了JAVA设计模式之访问者模式.分享给大家供大家参考,具体如下: 访问者模式: 一个作用于某对象结构中各元素的操作,使你可以在不改变各元素类数据结构的前提下增加作用于这些元素的新操作. 结构对象是访问者模式必备条件,且这个结构对象必须存在遍历自身各个对象的方法. 适用于:数据结构相对稳定,把数据结构和作用与其上的其它操作解耦,使得操作相对自由. 优点: 1.符合单一职责原则 2.扩展性良好:元素类可以通过接受不同的访问者来实现对不同操作的扩展. 缺点: 1.如果要增加新元素,则会让操

  • JAVA设计模式之建造者模式原理与用法详解

    本文实例讲述了JAVA设计模式之建造者模式定义与用法.分享给大家供大家参考,具体如下: 建造者模式:将复杂对象的构造与它的实现相分离,让相同的构建过程可以创建不同的对象. 适用场合: 复杂对象的算法应该独立于该对象的组成部分或当构造过程允许被构造不同的对象时. 组成角色: 1 创建者(Builder)接口:为创建一个对象的对应部件所指定抽象接口. 2 具体创建者(ConcreteBuilder):实现Builder的接口以构造对象的各个部件. 3 具体创建者管理对象(Director):使用Bu

  • JAVA设计模式之组合模式原理与用法详解

    本文实例讲述了JAVA设计模式之组合模式.分享给大家供大家参考,具体如下: 组合(整体与部分关系)模式:将不同但是相关的对象组合成树形结构以实现"部分-整体"的层次结构,使得用户对单个对象和组合对象的使用具有一致性. * 模式角色组成: 1.Component对象: 是组合中的对象接口,是所有类共有的接口.是用于统一定义整体中的部分. 2.Leaf对象: 整体中的部分,没有下一级. 3.Composite对象: 用来存储子部件,在Component接口中实现与部分有关操作. 以公司构成

  • Java设计模式之代理模式与装饰模式实例详解

    本文实例讲述了Java设计模式之代理模式与装饰模式.分享给大家供大家参考,具体如下: 之所以把这两种模式放在一起说,是因为我发现这了两种模式几乎一模一样! 从网上也搜了一些资料,发现两者还是有一些区别的.我们在学习的同时也把这种困惑搞清楚. 定义: 代理模式,为其他对象提供一种代理以控制对这个对象的访问. 装饰模式,动态地给一个对象添加一些额外的职责. 代理模式,很好理解,就是把一个对象再次封装,以后就对封装的对象访问就可以了. 因为代理对象已经取代了被代理对象. 装饰模式,给一个对象增加功能,

随机推荐