주위 또한, 나에게 물었다 나는 많은 친구를했다. 나사가 들어 가지 조, 많은 사람들이 의심의 여지가, 왜 인터뷰 원리를 물어 소스를 부탁했지만, 실제 작업에 대한 액세스 권한, 즉, 우리가 흔히 말하는 인터뷰가 로켓을하지 소스 코드에 보이지 않는,하지만 원칙, 방법들은 기본적으로 두 단어 :? 나에게 답을 준 문제 해결 않을 경우 그들에 대한 내 대답은 "검색."
실제로, 대부분의 문제의 작품은 오류 메시지 검색을 복사하여 해결 될 수 있으며, 점점 더 많은 사람들이 아주 쉬운을 개발했다 그래서 지금 더 많은 프레임 워크, 프로그래밍 플러스 검색 엔진의 블록을 구축 싸움 사물의 환상. 난 항상 약간의 검색을주고 싶었다는 이유 예제 이해하기 위해 소스 코드에 따라,보다 발견했다.
이것은 나는 좋은 친구가 나에게 이러한 질문을 가지고, 지난 해 8 월에 일이 일어났다 고 말했다.
내가 빈 문자열을 전달하지만, 사용하는 이유는 무엇입니까 라벨의 MyBatis 판단은 빈 문자열 == 0 설립으로 밝혀졌다 경우
우리의 지식에서 빈 문자열과 0 같은 숫자는 불가능하다. 내 첫 반응은 그가 사용 권리 아니었다? 아니면 코드의 다른 부분을 방해하는 그의 사업이었다? 그래서 내가 쓰기로했다 그래서 테스트를위한 가장 간단한 데모. 아래
그리고, 다음과 같은 결과가 출력 :
놀랍게도이 정말 빈 문자열 및 태그 번호가 0이되면 결정되는 것을 발견했다.
여기에 내가이 문제가 발생 속이려고하고 있지 않다, 솔직히 첫 번째 반응을 볼 수있는 소스 코드가 분명하지 물론, 검색 브라우저를 열 수 있습니다. 우리의 검색의 주요 방향이 거기에, 하나는 레이블 경우 MyBatis로 원칙을 결정하는 것입니다, 라벨은 빈 문자열 및 0가 동일한 경우는 왜 MyBatis로. 그것은 발견, 우리는 (당신이 스스로를 검색 할 수 있습니다) 답을 찾으려하지 않았다.
물론, 비록이 검색에 만족스러운 답은 없지만, 우리는 또 다른 예를 발견했다.
나는 우리가이 심판과 유사한 프로젝트 코드가 많은이 있었다 전망이다.
<시험 = "UID! = null이 UID! = '' '의 경우> </ IF>
우리는 일반적으로 동료의 많은 복사 붙여 넣기처럼, 개발!
어떤 문제가있을 것입니다 그래서 사본이 마지막에 붙여 넣 생각없이, 우리는 다음과 같은 예를 살펴
这个判断虽然是复制黏贴一把梭出来的,但是从我们的认知上来说,这个对象确实不是null,也不等于空字符串,所以这个判断应该是true的,但是运行结果如下:
果然,这个又颠覆了我们的认知,但是如果你遇到的是案例2这种情况还比较好搜索,还是能搜到解决方案,如下图
其实这两个案例都是一个问题,那就是这个if标签,把0和空字符串判断成了相等.
这个时候要敲黑板划重点了,俗话说一朝被蛇咬十年怕井绳,虽然第二个例子我们有了解决方案,但是这些解决方案都是治标不治本,如果我们没弄懂这其中的原理,那么你心里永远是有一块疙瘩的.你害怕下一次,又有奇奇怪怪的事情发生,只有弄懂原理,才能从根源解决问题,也就是解决一类问题,而不是某一个问题.
同时我也认识到,机会来了,终于找到一个为什么要看源码的比较合适例子了
分析源码
由于链路比较长.这里就不把debug过程展示了(对Mybatis执行流程不熟悉的,可以看看我之前的别怕看源码,一张图搞定Mybatis的Mapper原理,然后顺着执行流程debug
我们拿第一个例子来分析,因为两个案例其实遇到的问题都是一样的.
如果上面看不懂,我这里可以简单描述一下:
首先他会获取两个判断对象的类型,当拿一个字符串和一个数字判断的时候,因为类型不一样嘛,当mybatis发现,这个字符串是可以转换成数字的,那么就会把这个字符串转成数字,然后再和这个数字判断.那么问题就来了,这个空字符串会转换成什么数字呢?
从源码的这个
return s.length() == 0 ? 0.0D : Double.parseDouble(s);
就可以看出,这个空字符串,是会被转成0的.所以现在一切豁然开朗.
但是源码是看了,问题还是没有解决啊.他里面其他类型判断的源码这么多,不可能全部看完,时间也不允许啊,万一还有其他坑怎么办.由此可见,只看源码还是不够的,还需要一些解决问题的分析思路,这就是为什么网上源码解析的文章这么多。
解决问题的思路
우리는 소스 코드를보고 있지만, 우리는 또한 규칙을 알고 우리가 확인해야 할, 불일치이다. 그러나 키가 솔직히. 첫 번째 반응은 소스 코드의 노래를 수정할 것이라고했다 많은 사람들을 문제 일을 해결한다. 그러나 방법이다, 당신은 제어 확실히 다른 문제로 이어질하지 않습니다, 유지 결정? 그래서, 문제를 해결하기 위해 생각의 방향이 나는 방향, 그것은 매우 중요 말했다 있습니다, 그래서 급하게 수정 된 소스 코드의 작은 조각 봐.
만약이 확실하지 익숙하지. 캡슐화, 상속, 다형성,하지만의 객체 지향. 다섯 개 가지 원칙 그래서 우리가 조금 이상 할 수 있습니다. 즉되고 객체 지향 한 후, 그 때의 세 가지 특징
- 단일 책임
- 개방 - 폐쇄 원칙
- 원칙적으로 인한 신뢰
- 인터페이스 독방 원리
- 리스 코프 치환 원칙
그럼 난이 상대적으로 간단한 설명이 바이두가 알고있는 것을 인용, 개방 및 폐쇄의 원칙에 대해 말했다
소프트웨어 엔티티 확장해야하고, 수정할 수 없습니다 : 개방 - 폐쇄 원칙은, 핵심 아이디어입니다. 즉 수정 폐쇄, 확장 오픈입니다.
당신이 디자인 패턴을 이해한다면, 다음이 무엇을 의미하는지 이해하는 것입니다. 당신이 이해하지 않는 경우, 당신은 서쪽으로 디자인 패턴을이 책을 볼 수, 정책 디자인 패턴을 소개하는 방법입니다. 간단하게, 그것은이다 당신이 경우 수요 증가 순전히를 결정하는 데 사용하는 경우 음, 증가보다 수요, 나는 단지를 추가해야합니다, 당신은 그 코드를 수정하는 경우 다 다른 사람을 추가해야합니다.하지만 좋은 디자인은해야한다 전략입니다. (당신이 학생들을 모르는 경우가 디자인 모드를 볼 것을 권장합니다) 구현 클래스는, 사실, SPI는 또한 개폐이 원칙의 아이디어가 포함되어 있습니다.
그런 좋은 프레임 워크를 MyBatis로. 사람들은 자연스럽게 객체 지향의 다섯 가지 원리를 이해하는 것은, 확실히이 원칙을 따릅니다. 당신이 경우이를 사용자 정의, 내부 멀티 클래스, 다음 클래스를 추가 할 수 즉, 그는 방법을 제공합니다 판사 규칙.
솔루션
우리는 클래스, 예를 들어, 내가 이름을 사용자 정의 FeiChaoOgnl
그리고 우리는이 표현에 와서
그럼 우리는 작업보고
FeiChaoOgnl는 한, 완벽하게 보완 결정이 문구에 따라 방법, 심지어 셔틀을 붙여 복사도 같이 크게 문제의 위험을 감소