java項目中要不要廢棄使用switch

先看switch是怎么產(chǎn)生的：

很久以前，計算能力很昂貴，電腦性能很差，人們便想著法子的提高執(zhí)行效率
先看看if(test==0)的處理邏輯：
先是把test的值放在一個寄存器中，然后把0放在另一個寄存器中，然后做減法，然后根據(jù)結果再判斷是否執(zhí)行后面的語句

再看看switch的處理邏輯：

switch是在編譯階段就將判斷條件和子函數(shù)地址邏輯綁定了，真正執(zhí)行的時候，直接將test映射到對應的地址中就行了。
而且break的出現(xiàn)是為了解決當時goto 任意一行的問題的，代表本次邏輯結束
很明顯，break的效率確實要比if好點，但再一想，也沒有太本質的區(qū)別，無非就是提前加載么

switch優(yōu)點：

1、代碼整潔，相比if-else，但也好不到哪里去
2、執(zhí)行效率快點，也是相比于if-else

switch缺點：

1、忘記寫break，很容易造成bug
2、太多的break，感覺代碼就很冗余，但不寫又不行
3、局限的case判斷條件

總結：

那么以現(xiàn)在計算能力，switch比if好的那點執(zhí)行效率，完全可以忽略不記了，而且sun官方也指出對if進行過效率優(yōu)化。
所以，switch的優(yōu)點基本被縮小到?jīng)]有了，而他的缺點卻一直存在，而且基本每個java開發(fā)者都被switch坑過。
那么我們?yōu)槭裁催€要繼續(xù)用switch呢？

網(wǎng)友有一種說法，邏輯判斷多于5次，就用switch，少于5次，就用if-else
或者另一種說法，5000次以上的邏輯判斷，用switch執(zhí)行比用if快將近一倍
對于這種說法，我是這樣理解的，首先我們想想，大段大段的邏輯判斷，是不是本身就有問題，
我們首先應該想到的是設計問題，為什么要出現(xiàn)這么多邏輯判斷，能不能規(guī)避，而不是一開始就想用哪個能更快
而且，java是一個面向對象的語言，如果大段大段的邏輯判斷，那不就是過于面向過程了么，這是不是又違背了java設計的初衷了呢

最后補充一點，我們還有設計模式，可以想辦法替代掉這種大段的邏輯判斷，詳細可以去搜搜替代ifelse的方案

總結

以上是生活随笔為你收集整理的我们的java项目，要不要废弃switch的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。