迪米特法则：电子商务库存管理应用案例，并不属于过度设计

最新推荐文章于 2024-08-06 10:22:43 发布
最新推荐文章于 2024-08-06 10:22:43 发布
阅读量1.1k 收藏 29
点赞数 24
分类专栏： 架构设计 spring boot Java 文章标签： 迪米特法则 架构设计 设计要素 java
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/alises1314/article/details/140375956
版权
Java 同时被 3 个专栏收录
137 篇文章 0 订阅
订阅专栏
spring boot
121 篇文章 0 订阅
订阅专栏
架构设计
14 篇文章 0 订阅
订阅专栏

在这里插入图片描述

迪米特法则（Law of Demeter, LoD）是一种软件设计原则，它要求一个对象应该对其他对象有最少的了解，只与直接的朋友（即直接的依赖关系）交互。

肖哥弹架构 跟大家“弹弹” 代码设计技巧，需要代码关注

欢迎 点赞，点赞，点赞。

关注公号Solomon肖哥弹架构获取更多精彩内容

历史热点文章

2. 迪米特法则设计图：

电子商务中库存服务如何遵守迪米特法则：

在这里插入图片描述

3. 迪米特法则解决什么：

迪米特法则解决了在复杂系统中对象之间不必要交互的问题，减少了系统的耦合度。

4.迪米特法则特点：
  • 最小化交互：类只与直接相关对象交互。
  • 提高模块化：降低了类之间的依赖，提高了系统的模块化。
5. 迪米特法则缺点：
  • 可能增加间接层：为了遵守迪米特法则，可能需要增加额外的间接层或中间类。
  • 过度封装：在一些情况下，可能会导致过度封装，影响代码的直观性。

6. 迪米特法则使用场景：

当系统中的对象之间存在复杂的交互关系，或者一个对象需要了解太多其他对象的内部细节时。

7. 迪米特法则案例

7.1 库存和订单处理案例

重构前：


    // OrderService 直接与 Product 交互，违反了迪米特法则
    public class OrderService {
        public void placeOrder(Product product, int quantity) {
            if (product.getStock() >= quantity) {
                product.reduceStock(quantity);
                product.getSupplier().notifyStockLevel(); // 间接交互
                // 发送订单确认逻辑
            } else {
                // 发送缺货通知逻辑
            }
        }
    }

    public class Product {
        private int stock;
        private Supplier supplier;

        public int getStock() {
            return stock;
        }

        public void reduceStock(int quantity) {
            stock -= quantity;
        }

        public Supplier getSupplier() {
            return supplier;
        }
    }

    public class Supplier {
        public void notifyStockLevel() {
            // 库存水平通知逻辑
        }
    }

问题分析：

  1. 高耦合度：OrderService 直接与 Product 类的多个方法交互，包括获取库存和减少库存，这增加了类之间的依赖。
  2. 低内聚性：Product 类不仅管理自己的状态，还负责与 Supplier 交互，这违反了单一职责原则。
  3. 扩展性差：当需要添加新的库存检查逻辑或供应商通知逻辑时，可能需要修改 OrderService 的代码，这限制了系统的扩展性。
  4. 代码重复：如果系统中的其他部分需要进行库存检查或减少库存，可能会复制 OrderService 中的代码，导致代码重复。
  5. 测试困难：直接依赖具体实现使得对 OrderService 进行单元测试变得复杂，因为它依赖于多个外部实体。

重构后：


    // 库存服务接口，定义库存相关操作的契约
    public interface IInventoryService {
        boolean isStockSufficient(Product product, int quantity);
        void reduceStock(Product product, int quantity);
    }

    // 实现库存服务接口的具体类
    public class InventoryService implements IInventoryService {
        @Override
        public boolean isStockSufficient(Product product, int quantity) {
            // 检查库存是否充足
            return product.getStock() >= quantity;
        }

        @Override
        public void reduceStock(Product product, int quantity) {
            // 减少产品库存
            product.reduceStock(quantity);
        }
    }

    // 订单服务类，负责处理订单逻辑
    public class OrderService {
        private IInventoryService inventoryService;

        // 依赖注入库存服务
        public OrderService(IInventoryService inventoryService) {
            this.inventoryService = inventoryService;
        }

        // 下订单的方法
        public void placeOrder(Product product, int quantity) {
            if (inventoryService.isStockSufficient(product, quantity)) {
                inventoryService.reduceStock(product, quantity);
                sendOrderConfirmationEmail(product, quantity);
            } else {
                sendOutOfStockNotificationEmail(product);
            }
        }

        private void sendOrderConfirmationEmail(Product product, int quantity) {
            // 发送订单确认邮件逻辑
            // 这里用注释代替真实的邮件发送逻辑
            // EmailService.send("Order confirmed for " + product.getName());
        }

        private void sendOutOfStockNotificationEmail(Product product) {
            // 发送缺货通知邮件逻辑
            // 这里用注释代替真实的邮件发送逻辑
            // EmailService.send("Out of stock notification for " + product.getName());
        }
    }

    // 产品类，包含库存和供应商信息
    public class Product {
        private int stock;
        private String name;
        private Supplier supplier;

        public Product(String name, int stock, Supplier supplier) {
            this.name = name;
            this.stock = stock;
            this.supplier = supplier;
        }

        public int getStock() {
            return stock;
        }

        public void setStock(int stock) {
            this.stock = stock;
        }

        public void reduceStock(int quantity) {
            stock -= quantity;
            if (stock <= 10) {
                supplier.notifyLowStock(this);
            }
        }

        public String getName() {
            return name;
        }
    }

    // 供应商类，负责接收库存水平通知
    public class Supplier {
        public void notifyLowStock(Product product) {
            // 库存水平通知逻辑，可能涉及外部系统或服务 ,篇幅问题省略
        }
    }

    // 客户端代码，使用OrderService和InventoryService
    public class ECommerceClient {
        public static void main(String[] args) {
            Product product = new Product("Laptop", 5, new Supplier());
            IInventoryService inventoryService = new InventoryService();
            OrderService orderService = new OrderService(inventoryService);

            // 尝试下订单
            orderService.placeOrder(product, 3);
            // 尝试下超过库存的订单
            orderService.placeOrder(product, 10); 
        }
    }

解决的问题：

  1. 解耦合：通过引入 IInventoryService 接口，OrderService 现在只依赖于库存服务的抽象，而不是具体的 Product 类。
  2. 高内聚性：Product 类现在只负责管理自己的状态，而库存检查和减少库存的逻辑由 InventoryService 处理，符合单一职责原则。
  3. 扩展性增强：新增或修改库存逻辑时，只需实现或修改 IInventoryService 的具体实现类，无需更改 OrderService。
  4. 减少代码重复：库存检查和减少库存的逻辑现在集中在 InventoryService 中，可以在多个地方重用，减少了代码重复。
  5. 易于测试：OrderService 和 InventoryService 可以独立测试，因为它们之间的依赖是通过接口定义的，可以轻松地使用模拟对象进行测试。
  6. 清晰的职责划分：每个类和接口都有明确的职责，OrderService 处理订单逻辑，InventoryService 处理库存逻辑，Product 管理产品状态。
  7. 更好的维护性：由于系统更加模块化，维护和更新特定部分的代码变得更加容易，因为对系统的其他部分的影响最小。

7.2 课程管理系统

重构前：

public class Professor {
    private String name;

    public Professor(String name) {
        this.name = name;
    }

    public void submitGrades(Student student, Course course, double grade) {
        course.getEnrolledStudents().add(student);
        student.addGrade(course, grade);
        System.out.println("Grade submitted by " + name);
    }
}

public class Course {
    private List<Student> enrolledStudents;

    public void addStudent(Student student) {
        enrolledStudents.add(student);
    }

    public List<Student> getEnrolledStudents() {
        return enrolledStudents;
    }
}

public class Student {
    private List<Grade> grades;

    public void addGrade(Course course, double grade) {
        grades.add(new Grade(course, grade));
    }
}

public class Grade {
    private Course course;
    private double grade;

    public Grade(Course course, double grade) {
        this.course = course;
        this.grade = grade;
    }
}

分析问题：

  1. 违反迪米特法则：Professor 类直接与 Student 和 Course 的具体实现交互。
  2. 高耦合度：Professor 类与 Course 和 Student 类的内部状态紧密耦合。
  3. 低内聚性：Course 类不仅管理课程信息，还管理学生注册和成绩记录。

重构后：


// 教授类，只负责教授相关逻辑
public class Professor {
    private String name;

    public Professor(String name) {
        this.name = name;
    }

    public void submitGrade(CourseGradeService courseGradeService, Course course, double grade) {
        courseGradeService.recordGrade(course, grade);
        System.out.println("Grade submitted by " + name);
    }
}

// 课程成绩服务，负责处理成绩记录逻辑
public class CourseGradeService {
    public void recordGrade(Course course, double grade) {
        course.addGrade(grade);
    }
}

// 课程类，只负责课程相关逻辑
public class Course {
    private List<Double> grades;

    public void addGrade(double grade) {
        grades.add(grade);
    }
}

// 学生类保持不变，只关注学生自己的成绩
public class Student {
    private List<Grade> grades;

    public void addGrade(Course course, double grade) {
        grades.add(new Grade(course, grade));
    }
}

// 成绩类保持不变
public class Grade {
    private Course course;
    private double grade;

    public Grade(Course course, double grade) {
        this.course = course;
        this.grade = grade;
    }
}

// 客户端代码
public class UniversityClient {
    public static void main(String[] args) {
        Professor professor = new Professor("Dr. Smith");
        Course course = new Course();
        CourseGradeService courseGradeService = new CourseGradeService();

        professor.submitGrade(courseGradeService, course, 92.5);
    }
}

解决的问题：

  1. 遵守迪米特法则：Professor 类现在只与 CourseGradeService 交互，而不是直接与 Course 或 Student 交互。
  2. 降低耦合度：通过引入 CourseGradeService，Professor 类不再依赖于 Course 类的内部实现。
  3. 提高内聚性：Course 类现在只关注课程和成绩管理，而 Professor 类只关注教授的行为。
  4. 增强扩展性：新增或修改成绩记录逻辑时，只需在 CourseGradeService 中进行，不影响其他类。
  5. 简化测试：可以独立测试 CourseGradeService 的行为，而不需要依赖 Professor 或 Course 类。
8. 参考开源框架：

在现代的电子商务平台中，如Magento或Shopify，通常会遵循迪米特法则来设计库存和订单服务。

9. 总结：

通过应用迪米特法则，电子商务平台的库存管理和订单服务变得更加清晰和解耦。这不仅提高了代码的可维护性，也使得新增功能或修改现有逻辑变得更加容易。迪米特法则是构建低耦合、高内聚系统的有效工具之一。

历史热点文章

Solomon_肖哥弹架构
关注
  • 24
    点赞
  • 踩
  • 29
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
专栏目录
Java的设计模式编程中迪米特法则的应用示例
09-02
在Java设计模式编程中，迪米特法则的应用有助于构建更稳定、更易于理解的代码结构。 首先，我们来分析一下违反迪米特法则的案例。在这个例子中，`CompanyManager` 类不仅与 `Employee` 和 `SubEmployee` 类直接交互...
C++设计模式迪米特法则实例
08-26
C++设计模式迪米特法则实例 迪米特法则是一种重要的设计模式，它也被称为最少知识原则（Least Knowledge Principle，LKP）。该原则的主要思想是，一个对象应当对其他对象有尽可能少的了解，或者说，不和陌生人说话...
电商项目中库存管理(问答式)
张肖的博客
06-15 8337
【今日话题】 电商项目的库存设计，如何不卖超，取消订单把库存加回去，不能多加 - 沈括号 1. 这个说一个之前处理并发的经验哈，情况应该是类似的，写sql的时候多加一个条件，用update tbl set col = col - num where col ≥ num,这样子吧 - 骑马爬树 2. 再加个定时任务去检查用户是否下单 没有的话 update
复杂系统设计基本注意事项
张彦峰的博客
10-22 3万+
系统复杂性是指系统的构建、运作和维护过程中涉及到的多个因素、组件、关系和交互的综合程度。认识软件的复杂性之前，需要找到合适的方法来度量一个软件系统是否复杂，以及复杂度有多少。
面试专区|【51道设计模式高频题整理(附答案背诵版)】
尺小闹的博客
07-02 1623
"高内聚"和"低耦合"是软件设计的两个重要原则，它们帮助我们提高代码的可读性、可维护性和可复用性。高内聚 (High Cohesion)内聚性是指模块内部元素之间的功能关联性。高内聚意味着一个模块或一个类只做一件事，它的责任清晰，所有的相关功能都集中在一起。例如，如果你有一个处理文件操作（如读取、写入、删除等）的类，那么这个类就应该只包含与文件操作相关的代码，而不应该包含其他与文件操作无关的功能，比如网络请求或者数据库查询等。提高了模块的独立性，使其更容易理解和维护。
大数据工程专业技术证书考试-数据分析与应用
m0_57280180的博客
08-30 6683
数据分析与应用根据大纲整理
java设计模式(1)
anotherQu的博客
10-13 907
1、设计模式概述 1.1 介绍 本教程来自http://c.biancheng.net/view/1317.html 目的是为了提高代码的可重用性、代码的可读性和代码的可靠性。 设计模式的本质是面向对象设计原则的实际运用，是对类的封装性、继承性和多态性以及类的关联关系和组合关系的充分理解。正确使用设计模式具有以下优点： 可以提高程序员的思维能力、编程能力和设计能力。 使程序设计更加标准化、代码编制更加工程化，使软件开发效率大大提高，从而缩短软件的开发周期。 使设计的代码可重用性高、可读性强、可靠性高、灵活
软件架构设计系列总结
09-26 252
架构引用维基百科：软件体系结构是构建计算机软件实践的基础。与建筑师设定建筑项目的设计原则和目标，作为绘图员画图的基础一样，一个软件架构师或者系统架构师陈述软件构架以作为满足不同客户需求的实际系统设计方案的基础。从和目的、主题、材料和结构的联系上来说，软件架构可以和建筑物的架构相比拟。一个软件架构师需要有广泛的软件理论知识和相应的经验来实施和管理软件产品的高级设计。软件架构师定义和设计软件...
架构设计
weixin_33713707的博客
08-27 326
架构引用维基百科：软件体系结构是构建计算机软件实践的基础。与建筑师设定建筑项目的设计原则和目标，作为绘图员画图的基础一样，一个软件架构师或者系统架构师陈述软件构架以作为满足不同客户需求的实际系统设计方案的基础。从和目的、主题、材料和结构的联系上来说，软件架构可以和建筑物的架构相比拟。一个软件架构师需要有广泛的软件理论知识和相应的经验来实施和管理软件产品的高级设计。软件架构师定义和设计软件的模块...
优秀程序员值得借鉴的一些信息
CSDN1332531529的博客
12-22 2778
目录 　　<1>:关于项目开发：项目的75个注意事项 　　<2>:关于程序员：程序员从初级到中级10个秘诀 　　<3>:关于软件设计：一些软件设计的原则 　　<4>:关于工作：每天写出好代码的5个建议 　　<5>:关于工作环境：程序员的工作效率和工作环境 <1>:关于项目开发： 项目的75个...
java基础002
热门推荐
u014163736的博客
04-29 4万+
试卷一2013年年底的时候，我看到了网上流传的一个叫做《Java面试题大全》的东西，认真的阅读了以后发现里面的很多题目是重复且没有价值的题目，还有不少的参考答案也是错误的，于是我花了半个月时间对这个所谓的《Java面试大全》进行了全面的修订并重新发布在我的CSDN博客。在修订的过程中，参照了当时JDK最新版本（Java 7）给出了题目的答案和相关代码，去掉了EJB 2.x、JSF等无用内容或过时内...
迪米特法则LoD.zip
01-10
迪米特法则（Law of Demeter，简称LoD）是面向对象设计中的一种重要原则，源自1987年在 Northeastern University 提出。这个法则旨在降低类与类之间的耦合，提高系统的可维护性和可扩展性。在中文环境中，迪米特法则...
迪米特法则_动力节点Java学院整理
08-29
迪米特法则_动力节点Java学院整理 迪米特法则是Java编程中一个重要的法则，它指导我们在类创建方法和属性时需要遵守的原则。下面我们将详细介绍迪米特法则的定义、问题由来、解决方案、优点和实践场景。 定义：...
设计模式七大原则（五）迪米特法则
weixin_43281498的博客
07-19 407
迪米特原则（Law of Demeter LoD）是指一个对象应该对其他对象保持最少的了解，又叫最少知 道原则（Least Knowledge Principle,LKP），尽量降低类与类之间的耦合。以上代码，Leader 只需要联系 employee 去统计课本数量得到结果，不需要与 book 建立联系。
J031_使用TCP协议支持与多个客户端同时通信
lzn20161229的博客
08-03 477
使用TCP协议支持与多个客户端同时通信。
C++ - 函数重载
最新发布
jiaowenjie的专栏
08-06 255
/打印的是第二个函数的地址。//打印的是第一个函数的地址。-> 重载函数在本质上是相互独立的不同函数。-> 函数返回值不能作为函数重载的依据。-> 重载函数的函数类型不同。**3.函数默认参数和函数重载****函数重载的注意事项：****4.函数重载的本质**
SpringBoot+Vue图书(图书借阅)管理系统-附项目源码与配套文档
m0_74283290的博客
08-03 1313
本论文阐述了一套先进的图书管理系统的设计与实现，该系统采用Java语言，结合现代Web开发框架和技术，旨在为图书馆提供高效、灵活且用户友好的资源管理解决方案。系统利用Spring Boot框架为核心，整合MyBatis ORM工具，以及MySQL数据库，构建了一个高性能、可扩展的后端服务。前端界面则采用了Vue.js框架，以提供流畅的用户交互体验。论文首先进行了详尽的需求分析，确定了系统的核心功能，包括图书的添加、编辑、删除、查询，读者的注册、登录、个人信息管理，以及图书的借阅、归还、续借流程。
枚举工具类
qq_43049583的博客
08-04 470
java枚举工具类
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Solomon_肖哥弹架构

你的欣赏就是我最大的动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值