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

你可能感兴趣的:(JAVA面试,迪米特法则,java,spring)