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、“为什么要用这个设计规则,有什么好处,有什么还出呢?”文章来源:https://www.toymoban.com/news/detail-469266.html
迪米特法则的核心观念就是:类之间解耦,弱耦合。耦合松了,类的复用性就提高了,以上这些事好处。如果面试还问到了坏处?你是不是要懵了,这TM的公认的设计规范,还有坏处?当然,很多东西它都是把双刃剑,解决了A问题,那么可能引起B问题。迪米特法则也不例外,它的坏处就是**类松耦合了,有可能会带来大量的中转调用,A要通过调用B,然后调用C,再调用D才能获取想要的结果。**这样调用的深度会让系统的复杂度提升,从而维护成本提升。成本提升了,老板就要暴怒了,TM的让你写个代码,你非要搞追求,搞情操,哈哈哈。
所以在遵循规范的同时,也要权衡可读性、维护性等因素,不可盲目炫技,为了实现而实现,搞得本末倒置。文章来源地址https://www.toymoban.com/news/detail-469266.html
到了这里,关于6大设计规则-迪米特法则的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!