多くの人々はつまり、なぜインタビュー原理をお願い致しソースを頼むが、実際の作業にはアクセスしたいと、私たちはしばしば言う、インタビューはロケットを作った、疑問を持って、ネジが入る締めます。私は多くの友人を持っているの周りにも、私に尋ねましたあなたがソースコードを見ていないではなく、原則として、どのように彼らは基本的に2つの単語:?私に答えを与えた問題解決しなければ、彼らに私の答えは、「検索」を
確かに、問題のほとんどの作業は、エラー・メッセージ検索をコピーすることによって解決することができ、そしてより多くの人々は非常に簡単に開発していたように、今より多くのフレームワークは、プログラミングに加えて、検索エンジンのブロックを構築戦います理由の例の意味を理解するために、ソースコードに依存するあまり、より物事の錯覚。私はいつも少し検索を与えたいと思っていますが見つかりました。
これは、昨年8月に起こった起こった、私は良い友人が私に、このような質問をしている、と彼は言いました。
私は空の文字列を渡しますが、使用しないのはなぜラベルMyBatisの判断は、空の文字列は== 0設立であることが判明した場合
私たちの知識から、空の文字列と0に等しい数が不可能です。私の最初の反応は、彼が使用権はなかったのか、それともコードの他の部分を妨害する彼のビジネスであるということでした？だから私は書くことにしたのでテストのための最も簡単なデモ。以下
そして、次のように結果が出力されます。
驚くべきことにこれは本当に空の文字列とタグ番号が0に等しくなるかどうかが決定されることがわかりました。
ここで私はこの問題が発生したカンニングしようとしているわけではない、率直に言って、最初の反応は、あなたを参照するには、ソースコードは確かではありません、もちろん、ブラウザ検索を開くことです。私たちの検索の主方向2があり、一つはラベル場合はMyBatisの原則を決定することで、ラベルが空の文字列で、0が等しい場合、なぜMyBatisの。それが発見された、私たちは（あなたが自分で検索することができます）答えを見つけるために望んでいませんでした。
もちろん、そこが検索に満足な答えはありませんが、我々は別の例を見つけました。
私たちは、この判断に同様のプロジェクトのコードが多くありましたべきだと考えています。
<もしテスト= "UID！= nullのとはuid！= ''"> </場合>
私たちは、通常の開発、私の同僚の多くは、コピーペーストのようなものです！
何か問題があるでしょうので、コピーは最後に貼り付け何も考えずに、私たちは、以下の例を見て
这个判断虽然是复制黏贴一把梭出来的,但是从我们的认知上来说,这个对象确实不是null,也不等于空字符串,所以这个判断应该是true的,但是运行结果如下:
果然,这个又颠覆了我们的认知,但是如果你遇到的是案例2这种情况还比较好搜索,还是能搜到解决方案,如下图
其实这两个案例都是一个问题,那就是这个if标签,把0和空字符串判断成了相等.
这个时候要敲黑板划重点了,俗话说一朝被蛇咬十年怕井绳,虽然第二个例子我们有了解决方案,但是这些解决方案都是治标不治本,如果我们没弄懂这其中的原理,那么你心里永远是有一块疙瘩的.你害怕下一次,又有奇奇怪怪的事情发生,只有弄懂原理,才能从根源解决问题,也就是解决一类问题,而不是某一个问题.
同时我也认识到,机会来了,终于找到一个为什么要看源码的比较合适例子了
分析源码
由于链路比较长.这里就不把debug过程展示了(对Mybatis执行流程不熟悉的,可以看看我之前的别怕看源码,一张图搞定Mybatis的Mapper原理,然后顺着执行流程debug
我们拿第一个例子来分析,因为两个案例其实遇到的问题都是一样的.
如果上面看不懂,我这里可以简单描述一下:
首先他会获取两个判断对象的类型,当拿一个字符串和一个数字判断的时候,因为类型不一样嘛,当mybatis发现,这个字符串是可以转换成数字的,那么就会把这个字符串转成数字,然后再和这个数字判断.那么问题就来了,这个空字符串会转换成什么数字呢?
从源码的这个
return s.length() == 0 ? 0.0D : Double.parseDouble(s);
就可以看出,这个空字符串,是会被转成0的.所以现在一切豁然开朗.
但是源码是看了,问题还是没有解决啊.他里面其他类型判断的源码这么多,不可能全部看完,时间也不允许啊,万一还有其他坑怎么办.由此可见,只看源码还是不够的,还需要一些解决问题的分析思路,这就是为什么网上源码解析的文章这么多。
解决问题的思路
私たちは、ソースコードを見ながら、我々はまた、ルールを知っていると我々は決定したい、矛盾である。しかし、重要な問題のことを解決する方法、である。多くの人々の最初の反応は、それがソースコードの聖歌を変更します。しかし、率直に言ってしまうということでした、そんなに急いで変更されたソースコードの小片を見て、制御を決定することができます維持され、確かにそれは非常に重要である、他の問題につながる？そうな問題を解決するための思考の方向、私は方向であることを特徴とすることに注意しません。
それが来るとき、それは確かに。カプセル化、継承、ポリモーフィズムが、オブジェクト指向の5つの原則不慣れではないオブジェクト指向の三つの特徴があれば。だから我々は少し奇妙かもしれません。つまり
- シングル責任
- オープンクローズ原理
- 原則的にその結果リライアンス
- インターフェイスの棲み分け原理
- リスコフの置換原則
それから私は、この比較的簡単な説明があるBaiduは知っている引用、開閉の原則について語りました
ソフトウェアエンティティは、スケーラブルであるべきであり、変更することはできません：オープンクローズ原理は、コアアイデアがあります。これは、拡張のために開いている、変更のため閉鎖。
あなたはデザインパターンを理解していれば、それはあなたがこれを理解していない場合、あなたは西のデザインパターンでこの本を見ることができます。これが何を意味するのか理解することです、ポリシーのデザインパターンを導入する方法である。単純に、それはありますあなたはそんなに、かどうかを判断するために、需要の増加を使用している場合さて、あなたはそれがコードを変更することで、場合マルチ他を追加する必要があります。しかし、良いデザインであるべき、増加需要よりも、私は追加する必要があります戦略です。（あなたは、学生がわからない場合、デザインモードを確認することをお勧めします）実装クラスは、実際には、SPIは、また、開閉のこの原則の考え方が含まれています。
このような良い枠組みMyBatisの。人々は自然にオブジェクト指向の5つの原則を理解し、確かにこの原則に従います。言い換えれば、彼はあなたがマルチクラスを追加するための方法を提供します、そのクラス内の、場合は、これをカスタマイズします裁判官のルール。
ソリューション
私たちは、私はそれを名付け、例えば、クラスをカスタマイズFeiChaoOgnl
その後、我々は、この文言に来ます
その後、我々は、操作を見て
FeiChaoOgnlは限り完全な補完を決定するための方法として、この文言によると、でも、シャトルをコピー＆ペーストも大いに問題のリスクを減少させます