6大设计规则-迪米特法则

妖狐艹你老母 2024-03-16 11:16 37阅读 0赞

tip: 作为程序员一定学习编程之道，一定要对代码的编写有追求，不能实现就完事了。我们应该让自己写的代码更加优雅，即使这会费时费力。

相关规则：

推荐：**[体系化学习Java（Java面试专题）][Java_Java]**

1.[6大设计规则-接口隔离原则][6_-]  
2.[6大设计原则-里氏替换原则][6_- 1]  
3.[6大设计规则-开闭原则][6_- 2]  
4.[6大设计规则-单一职责原则][6_- 3]  
5.[6大设计规则-依赖倒置原则][6_- 4]

#### 文章目录 ####

*  迪米特法则
 *   *  一、关于迪米特法则的一个小例子
     *  二、为什么要使用迪米特法则

## 迪米特法则 ##

《设计模式之禅》第5章介绍关于迪米特法则，总结真言：只和你关系好的朋友交流。  
这个真言怎么理解呢？迪米特法则在书中有个英文解释：Only talk to your immedate friends，翻译过来就是至于你直系的朋友沟通。按我的理解就是\*\*“各司其职”\*\*。

在介绍例子之前，我官方的介绍一下它，迪米特法则，也称为**最少知识原则**，定义是这样的：一个对象应该对其他对象最少得了解。

### 一、关于迪米特法则的一个小例子 ###

接下来我举个例子说明下：

> 场景：我们需要开发一个首页上展示用户注册数量的功能，我们需要给前端提供一个接口查询用户数量的。

很多同学肯定说，这我会啊，不就是controller、service、mapper的增删改查的那一套嘛，这熟悉的不能再熟悉了。但是你可不一定能写的规范，即使写规范了，你知道为什么要这么写吗？对于这个场景的实现有两种不规范的情况：

1、IndexController 里调用 IndexService，然后 IndexServiceImpl 里调用 UserMapper 查询用户数量，这种写法可能在很多大家做过的项目中非常常见，这种写法没有错，只是不符合**单一职责**原则，并且也不符合\*\*“功能内聚”\*\*的规范。

2、直接在 IndexController 里调用 UserMapper，其实这个就是不符合迪米特法则 ，Controller 很清楚的定义，就是请求的前置处理，处理一些接口参数校验，包括一些转换等，而 Service 的定义则是业务处理，如果要在 Controller 里查询，处理业务逻辑，本身功能不会出错，但是不符合规范，不符合迪米特法则 ，**“没有各司其职，是一种越俎代庖的表现”**。

package com.pany.camp.design.principle.demeter;
    
    import lombok.RequiredArgsConstructor;
    import org.springframework.stereotype.Service;
    
    /**
     *
     * @description:  用户实现
     * @copyright: @Copyright (c) 2022 
     * @company: Aiocloud
     * @author: panyong 
     * @version: 1.0.0 
     * @createTime: 2023-05-30 22:55
     */
    @Service
    @RequiredArgsConstructor
    public class UserServiceImpl implements UserService {
        
    
        private UserMapper userMapper;
    
        @Override
        public Integer doSearchRegisterUserNum() {
        
            return userMapper.findActiveUserCount();
        }
    }

package com.pany.camp.design.principle.demeter;
    
    /**
     *
     * @description: 用户接口
     * @copyright: @Copyright (c) 2022 
     * @company: Aiocloud
     * @author: panyong 
     * @version: 1.0.0 
     * @createTime: 2023-05-30 22:54
     */
    public interface UserService {
        
        
        /**
         * 查询用户注册数量
         * 
         * @since 1.0.0
         * @param
         * @return: java.lang.Integer 
         * @author: panyong 
         * @version: 1.0.0 
         * @createTime: 2023-05-30 23:07 
         */  
        Integer doSearchRegisterUserNum();
    }

package com.pany.camp.design.principle.demeter;
    
    
    /**
     *
     * @description:  用户持久层接口
     * @copyright: @Copyright (c) 2022 
     * @company: Aiocloud
     * @author: panyong 
     * @version: 1.0.0 
     * @createTime: 2023-05-30 23:09
     */
    public interface UserMapper {
        
    
        /**
         * 查询用户注册数量
         *
         * @since 1.0.0
         * @param
         * @return: java.lang.Integer
         * @author: panyong
         * @version: 1.0.0
         * @createTime: 2023-05-30 23:09
         */
        Integer findActiveUserCount();
    }

### 二、为什么要使用迪米特法则 ###

我们面向面试说下为什么要使用迪米特原则，因为面试官可能这样问你：“你知道哪些设计规则？” 、“为什么要用这个设计规则，有什么好处，有什么还出呢？”、“举一个使用这个规则的场景说明一下”等等。

**1、“为什么要用这个设计规则，有什么好处，有什么还出呢？”**

迪米特法则的核心观念就是：**类之间解耦，弱耦合。耦合松了，类的复用性就提高了**，以上这些事好处。如果面试还问到了坏处？你是不是要懵了，这TM的公认的设计规范，还有坏处？当然，很多东西它都是把双刃剑，解决了A问题，那么可能引起B问题。迪米特法则也不例外，它的坏处就是\*\*类松耦合了，有可能会带来大量的中转调用，A要通过调用B，然后调用C，再调用D才能获取想要的结果。\*\*这样调用的深度会让系统的复杂度提升，从而维护成本提升。成本提升了，老板就要暴怒了，TM的让你写个代码，你非要搞追求，搞情操，哈哈哈。  
所以在遵循规范的同时，也要权衡可读性、维护性等因素，不可盲目炫技，为了实现而实现，搞得本末倒置。

[Java_Java]: https://blog.csdn.net/qq_37967783/article/details/130940512
[6_-]: https://blog.csdn.net/qq_37967783/article/details/130977528
[6_- 1]: https://blog.csdn.net/qq_37967783/article/details/130966812
[6_- 2]: https://blog.csdn.net/qq_37967783/article/details/130956321
[6_- 3]: https://blog.csdn.net/qq_37967783/article/details/130960985
[6_- 4]: https://blog.csdn.net/qq_37967783/article/details/130977079