还有这种操作?浅析为什么要看源码

前言

很多人都有一个疑惑,为什么面试都喜欢问原理,问源码.但是实际工作根本用不上,也就是大家常说的,面试造火箭,进去拧螺丝.我身边也有不少朋友问过我,我给他们的回答是.如果不看源码,不懂原理,出了问题你怎么解决?他们给我的答复基本都是两个字,"搜索"

也确实,工作中大部分问题通过复制错误信息搜索都能解决,加上现在框架越来越多,拼积木式的编程方式加上搜索引擎,让越来越多人产生了开发是件很容易的事的错觉.我也一直想举一个搜索几乎搜不到,要看源码才能弄懂其中缘由的例子.

正巧这件事发生在了去年8月份,我一个很好的朋友问了我这么个问题,他说

为什么我传的是空字符串,但是用Mybatis的if标签判断该空字符串 == 0 竟然是成立的

从我们的认知上来说,一个 空字符串 和 一个数字0 是不可能相等的.所以我第一反应是,他是不是用法不对?或者是他的业务代码其他地方干扰到了? 于是我决定写了个最简单的demo来进行测试.如下

然后输出结果如下:

惊奇的发现,这个if标签果然把空字符串和数字0判断成了相等.

这里我并不想骗大家,遇到这种问题,坦白说第一反应当然不是看源码啦,当然是打开浏览器搜索一下.我们搜索的方向主要有两个,一个是mybatis if标签的判断原理,一个是为什么mybatis if标签空字符串和0是相等的.结果发现,并没有找到我们要想的答案(大家可以自行搜索一下).

当然虽然没有搜索到满意的答案,但是我们却发现了另一个例子.

我相信类似这种判断的代码大家项目中应该出现了很多.

1<if test="uid != null and uid != '' ">
2</if>

我们平时开发中,很多同事都是喜欢复制黏贴!

那么不假思索的复制黏贴到底会有什么问题呢,我们来看下面这个例子

这个判断虽然是复制黏贴一把梭出来的,但是从我们的认知上来说,这个对象确实不是null,也不等于空字符串,所以这个判断应该是true的,但是运行结果如下:

果然,这个又颠覆了我们的认知,但是如果你遇到的是案例2这种情况还比较好搜索,还是能搜到解决方案,如下图

其实这两个案例都是一个问题,那就是这个if标签,把0和空字符串判断成了相等.

这个时候要敲黑板划重点了,俗话说一朝被蛇咬十年怕井绳,虽然第二个例子我们有了解决方案,但是这些解决方案都是治标不治本,如果我们没弄懂这其中的原理,那么你心里永远是有一块疙瘩的.你害怕下一次,又有奇奇怪怪的事情发生,只有弄懂原理,才能从根源解决问题,也就是解决一类问题,而不是某一个问题.

同时我也认识到,机会来了,终于找到一个为什么要看源码的比较合适例子了

分析源码

由于链路比较长.这里就不把debug过程展示了(对Mybatis执行流程不熟悉的,可以看看我之前的别怕看源码,一张图搞定Mybatis的Mapper原理,然后顺着执行流程debug)

我们拿第一个例子来分析,因为两个案例其实遇到的问题都是一样的.

如果上面看不懂,我这里可以简单描述一下:

首先他会获取两个判断对象的类型,当拿一个字符串和一个数字判断的时候,因为类型不一样嘛,当mybatis发现,这个字符串是可以转换成数字的,那么就会把这个字符串转成数字,然后再和这个数字判断.
那么问题就来了,这个空字符串会转换成什么数字呢?

从源码的这个

1return s.length() == 0 ? 0.0D : Double.parseDouble(s);

就可以看出,这个空字符串,是会被转成0的.所以现在一切豁然开朗.

但是源码是看了,问题还是没有解决啊.他里面其他类型判断的源码这么多,不可能全部看完,时间也不允许啊,万一还有其他坑怎么办.由此可见,只看源码还是不够的,还需要一些解决问题的分析思路,这就是为什么网上源码解析的文章这么多,我们还要关注一下肥朝的博客^_^

解决问题的思路

我们虽然看了源码,我们也知道了这个判断的规则和我们想要的,是有出入的.但是关键是,怎么解决问题嘛.很多人第一反应是,那就修改源码呗.但是坦白说,你只看了这么一小片源码就贸然修改,确定能驾驭得住,确定不会引发其他问题?所以这个解决问题的思考方向,注意,我说的是方向,是非常重要的.

如果说到面向对象的三大特性,那么大家想必都不会陌生.封装、继承、多态.但是面向对象的五大原则.那么大家可能就稍微要陌生了.那就是

单一职责
开闭原则
依赖导致原则
接口隔离原则
Liskov替换原则

那我就说一下开闭原则,引用一下百度知道里面比较简短的描述是这样的

开放封闭原则，其核心思想是：软件实体应该是可扩展的，而不可修改的。也就是，对扩展开放，对修改封闭的。

如果你对设计模式有所了解的话,就很能了解这句话的意义.如果对这个不理解的,可以看一下大话设计模式这种书中,是如何引入策略设计模式的.简单的说是这样的,如果你是用if判断,那么多增加一个需求,你就要多增加一个else if,那就是要修改代码了.但是好的设计应该是,多增加一个需求,我只需要多增加一个实现类,也就是一种策略.(如果还不清楚的同学,建议看看设计模式),其实SPI,也是包含这种开闭原则的思想的.

Mybatis这么优秀的框架.人家自然明白面向对象的五大原则,所以必定会遵循这个原则.也就是说,他一定会提供一个方式,让你多增加一个类,然后这个类里面,来自定义这个if的判断规则.

解决方案

我们自定义一个类,就比如我取名为FeiChaoOgnl

然后我们的写法变成这样

那么我们运行看看

只要把FeiChaoOgnl判断方法补充完整,按照这个写法,就算是复制黏贴一把梭,出问题的风险也大大降低

写在最后

其实只要认准了解决问题的方向,那么解决问题,自然是水到渠成的事.这个解决问题的思路,才是本篇内容最具有核心价值的地方.我之前的源码解析文章,都在不断灌输原理,分析思路.同样的,这篇也不会例外.因为我想告诉大家的是一个解决问题的思路,是一个一通百通的分析方法.而不仅仅是某一个问题的解决方案.这也是肥朝博客的初心,我也希望能够一直做到不忘初心.

鉴于肥朝才疏学浅,文中不足之处还望你不吝斧正.

前言

分析源码

解决问题的思路

解决方案

写在最后

更多相关文章

随机推荐