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

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

相关规则：

推荐：体系化学习Java（Java面试专题）

1.6大设计规则-接口隔离原则
2.6大设计原则-里氏替换原则
3.6大设计规则-开闭原则
4.6大设计规则-单一职责原则
5.6大设计规则-依赖倒置原则

迪米特法则

《设计模式之禅》第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;

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 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的让你写个代码，你非要搞追求，搞情操，哈哈哈。
所以在遵循规范的同时，也要权衡可读性、维护性等因素，不可盲目炫技，为了实现而实现，搞得本末倒置。