嘁,都2020了,你咋還在單純的使用if-else
在高階語言中，基本上都提供了像if-else 和switch-case 這樣的條件語句，方便大夥進行判斷——載入程式走向。我們在寫程式時，常常需要指明兩條或者更多的執行路徑，使得程式執行時，能夠選擇其中一條路徑，去執行相應的語句，產生對應的結果 —— 這也是條件語句在程式中的作用。
if-else的例子
各位在初學C語言時，應該都寫過這樣一個程式：輸出每個月的天數：
//C語言程式碼片段
int Days(int months,int years){
int days;
if(months==1 || months==3 || months==5 || months==7 || months==8 || months==10 || months==12){
days=31;
}else if(months==2){
if((years%4==0 && years%100!=0) || years%400==0){
days=29;
}else{
days=28;
}
}else if(months==4 || months==6 || months==9 || months==11){
days=30;
}else{
printf("輸入錯誤！請重新輸入：\n");
Days(months,years);
}
return days;
}這個程式雖是“耳熟能詳”的，但後來看著未免感覺有些【繁瑣】，多層if-else的巢狀不僅使得可讀性降低，還會大大影響程式執行的效率。。。
if-else的問題
從上面就可以看出，if-else判斷語句使用起來非常簡單，但是在稍微複雜的邏輯場景下，對if-else的頻繁使用（或說：濫用）就會容易導致整個專案的可讀性和可維護性大大降低。
我們可以試想一下，如果專案中出現了一種新的情況，那麼我們要在原有的程式碼基礎上繼續增加if-else。但是需求是不會減少的。這樣惡性迴圈下去，原本的幾個if-else可能在更新了幾個版本後變成了幾十個，這可真是令人哭笑不得的事。
（當然，現在也許你的公司會有硬性要求，或者開發模板，那就恭喜你了…）
從設計模式的角度考慮，if-else簡直具有了“壞”程式碼具有的一切：
- 資料和實現邏輯強耦合
- 擴充套件麻煩，維護性低
改善if-else
if-else並非是需要全部被代替的，確切的說，我們現在只能去不斷的改善它，使他執行的更為【流暢】。
短路符號和三元表示式
前幾天筆者還在群裡說這兩個：短路符號，又叫“邏輯運算子”，在一些簡單的場景下，我們完全可以用它來代替if-else（尤其是那些需要“幾個條件同時滿足”的場景下）：
比如這個——判斷一個數是不是2的冪：
//c++程式碼片段
class Solution {
public:
bool isPowerOfTwo(int n) {
//如果一個數是 2 的次方數的話，那麼它的二進數必然是最高位為1，其它都為 0 ，
//那麼如果此時我們減 1 的話，則最高位會降一位，其餘為 0 的位現在都為變為 1，
//那麼我們把兩數相與，就會得到 0
return (n > 0) && (!(n & (n - 1)));
}
};我們也可以用三元符號來代替if-else，它是幾乎最合適的計算機判斷符號（筆者自認為！），尤其適用於多條件複合判斷（一層巢狀一層）。不過需要注意的是，大量的三元運算子卻容易影響程式碼的可讀性：
比如——判斷 n! 結果尾數中零的數量：
//java程式碼片段
public class Solution {
public int trailingZeroes(int n) {
//不斷遞迴
return n == 0 ? 0 : n / 5 + trailingZeroes(n / 5);
}
}
當然，我們還有一種改進方法：如果每種條件下程式碼邏輯比較多，也可以考慮提前跳出來結束函式——這是借鑑了for迴圈。
說說switch-case
switch-case是語言自身提供的另一種條件語句，它和if在本質上並沒有什麼區別，只是程式碼看上去會更簡潔。比如——判斷年齡：
goodswitch(age){
case 10:
break;
case 20:
break;
case 30:
break;
//...
}
但是switch-case無法從根本上解決多個相似條件下需要多次重複的問題。
表驅動法
這個是筆者最為推崇的一種寫法，它幾乎在大資料量判斷、範圍區別處理等問題上都有解決方案！
現在讓我們再來看文章開頭那道題：輸出每個月有多少天
我們不妨轉換一下思路，每個月份對應一個數字，而月份都是按順序排列的，所以我們是否可以用一個數組來儲存天數，然後用下標來訪問？
//javascript 語法片段 const month=new Date().getMonth(),year=new Date().getFullYear(),isLeapYear=year%4==0 && year%100!=0 || year%400==0; const monthDays=[31,isLeapYear ? 29 : 28,31,30,31]; const days=monthDays[month];
哦，這個程式碼執行起來可簡單多了——至少看起來是這樣。
還有上面判斷年齡的程式碼，我們也可以這樣寫：
//JavaScript 語法片段
ages=[10,20,...];
funs=['a1','a2',...];
for(let i in ages){
if(age==ages[i]){
funs[i]();
}
}
function a1(){
}
function a2(){
}
//...
看了兩個例子，想必你對【表驅動法】有了瞭解：
表驅動法就是一種程式設計模式，從表裡面查詢資訊而不使用邏輯語句。事實上，凡是能通過邏輯語句來選擇的事物，都可以通過查表來選擇。對簡單的情況而言，使用邏輯語句更為容易和直白。但隨著邏輯鏈的越來越複雜，查表法也就愈發顯得更具吸引力。——《程式碼大全》
使用表驅動可不像if-else那樣“輕鬆”，我們需要先思考兩個問題：
如何從表中查詢資料？如果if-else判斷的是範圍，該怎麼查？查什麼？（資料？索引？）
基於這兩個問題，有人將依據表驅動的查詢分為三種：
直接訪問索引訪問階梯訪問
1、直接訪問表
筆者最近按照母親的“旨意”跑了一趟保險公司，發現這個保險費率非常麻煩——它會根據年齡、性別、婚姻狀態等不同情況變化。看著上面輸出日期的程式想一下，如果你用邏輯控制解構（if or switch）來表示不同費率，那會有多麻煩！（事實上，你的程式碼可能會像八爪魚一樣…）
我們能夠知道，這裡的【年齡】是個範圍！沒法用陣列或者物件來做對映。這有兩種解決方案：直接訪問表 or 階梯訪問表。筆者決定先試試“直接訪問表”的方式，並找到了兩種方法：
複製資訊從而能夠直接使用鍵值：我們可以給 1-17 年齡範圍的每個年齡都複製一份資訊，然後直接用 age 來訪問，同理對其他年齡段的也都一樣。這種方法在於操作很簡單，表的結構也很簡單。但有個缺點就是會浪費空間，畢竟生成了很多冗餘資訊。（不建議使用）轉換鍵值，如果我們把年齡範圍轉換成鍵呢？這樣就可以直接來訪問了，唯一需要考慮的問題就是有些情境下年齡如何轉換為鍵值。
對於第二種方法，有人可能疑惑了：還要用if-else轉換？ 當然。前面已經說過：簡單的if-else不會有什麼問題的，表驅動只是為了優化複雜的邏輯判斷，使其更靈活、易擴充套件。
//TypeScript 語法片段
const Age={
0:"unadult",1:"adult"
}
const Gender={
0:"female",1:"male"
}
const Marry={
0:"unmarried",1:"married"
}
const rateMap={
[Age[0]+Gender[0]+Marry[0]]:0.1,[Age[0]+Gender[0]+Marry[1]]:0.2,[Age[0]+Gender[1]+Marry[1]]:0.3,[Age[0]+Gender[1]+Marry[0]]:0.4,[Age[1]+Gender[0]+Marry[0]]:0.5,[Age[1]+Gender[0]+Marry[1]]:0.6,[Age[1]+Gender[1]+Marry[1]]:0.7,[Age[1]+Gender[1]+Marry[0]]:0.8
}
const isAdult=(age:number)=>age>=18 ? 1: 0
const getDate=(age,hasMarried,gender)=>{
age=isAdult(age)
return rateMap[Age[age]+Gender[gender]+Marry[marry]]
}
這樣才是正確的開啟方式嘛！
哦對，剛剛好像還說了一種方法：
2、階梯訪問表
同樣是為了解決上面那個年齡範圍的問題，階梯訪問沒有索引訪問直接，但是會更節省空間。
為了使用階梯方法，你需要把每個區間的上限寫入一張表中，然後通過迴圈來檢查年齡所在的區間，所以在使用階梯訪問的時候一定要注意檢查區間的端點。
//TypeScript 語法片段
const ageRanges:number[]=[17,65,100],keys:string[]=['<18','18-65','>65'];
const getKey=(age:number):string=>{
for(let i in keys){
//console.log(i);
//console.log(ageRanges[i]);
if(age<=ageRanges[i]){
return keys[i];
}
}
return keys[keys.length-1];
}
3、索引訪問表
實際中的保險費率問題，在處理年齡範圍的時候很頭疼，這種範圍往往不像上面第一種方法中那麼容易得到 ‘key'。
我們當時提到了複製資訊從而能夠直接使用鍵值，但是這種方法浪費了很多空間，因為每個年齡都會儲存著一份資料。
但是如果我們只是儲存索引，通過這個索引來查詢資料呢？
假設人剛出生是0歲，最多能活到 100 歲，那麼我們需要建立一個長度為 101 的陣列，陣列的下標對應著人的年齡，這樣在 0-17 的每個年齡我們都儲存 ‘<18'，在18-65儲存 ‘18-65',在65以上儲存 ‘>65'。這樣我們通過年齡就可以拿到對應的索引，再通過索引來查詢對應的資料。
看起來這種方法要比上面的直接訪問表更復雜，但是在一些很難通過轉換鍵值、資料佔用空間很大的場景下可以試試通過索引來訪問：
//Typescript 程式碼片段 const ages:string[]=['<18','<18',...'18-65',...'>65','>65',...'>65']; const ageKey:string=ages[age];
這樣雖然在造表的時候稍有些麻煩，但是在處理資料時卻是異常簡便！
表驅動的典型應用
表驅動最大的意義就是將條件判斷（資料）和邏輯剝離分開，將條件用可配置的表（物件 or 陣列）來管理
將0-360°劃分為8個不同的空間，但不要總是用if-else實現：
//JavaScript 程式碼片段
const keys=['A','B','C','D','E','F','G','H'],range=[45,90,135,180,225,270,315,360];
const degreeTkey=(rage)=>{
for(let i in range){
if(rage<=range[i]){
return keys[i];
}
}
}
const map={
'A':()=>{
//...
},'B':()=>{
//...
},//...
}
//呼叫如：
map[degreeTkey(46)]();
列舉解決if-else對應關係複雜的問題
啥角色幹啥事，這是一個很明顯的對應關係，所以學過的“列舉”為啥不用？
其實列舉和上面提到的【表搜尋】很像：我們舉一個“系統管理員操作許可權”的問題
首先定義一個公用介面 RoleOperation，表示不同角色所能做的操作：
public interface RoleOperation {
String op();//表示某個角色可以做哪些op操作
}
接下來我們將不同角色的情況全部交由列舉類來做，定義一個不同角色有不同許可權的列舉類 RoleEnum：
public enum RoleEnum implements Role0peration {
//系統管理員(有A操作許可權)
ROLE_ ROOT_ _ADMIN {
@Override
public String op() {
return "ROLE_ ROOT_ ADMIN:" + " has AAA permission";
}
},//訂單管理員(有B操作許可權)
ROLE_ ORDER_ ADMIN {
@override
public String op() {
return "ROLE_ ORDER_ _ADMIN:" + " has BBB permission";
}
},//普通使用者(有C操作許可權)
ROLE_ NORMAL {
@Override
public String op() {
return "ROLE_ NORMAL:" + "has CCC permission";
}
};
}
而且這樣一來，以後假如我想擴充條件，只需要去列舉類中加程式碼即可，而不是去改以前的程式碼，這豈不很穩！
public class JudgeRole {
public String judge( String roleName ) {
//一行程式碼搞定!之前的if/else沒了!
return RoleEnum.va1ue0f(roleName).op();
}
}
工廠模式解決if-else“分支過多”問題
不同分支做不同的事情，很明顯就提供了使用工廠模式的契機，我們只需要將不同情況單獨定義好，然後去工廠類裡面聚合即可。
首先，針對不同的角色，可以單獨定義其業務類：
//系統管理員(有A操作許可權)
public class RootAdminRole implements Role0peration {
private String roleName ;
public RootAdminRole( String roleName){
this.roleName = roleName ;
}
@Override
public String op() {
return roleName + "has AAA permission" ;
}
}
//訂單管理員(有B操作許可權)
public class OrderAdminRole implements RoleOperation {
private String roleName ;
public OrderAdminRole( String roleName ) {
this.roleName = roleName ;
}
@Override
public String op() {
return roleName + "has BBB permission";
}
}
//普通使用者(有C操作許可權)
public class NormalRole implements RoleOperation {
private String roleName ;
public NormalRole( String roleName){
this.roleName = roleName;
}
@Override
public String op() {
return roleName + "has CCC permission";
}
}
接下來再寫一個工廠類 RoleFactory對上面不同角色進行聚合：
public class RoleFactory {
static Map<String,Role0peration> roleOperationMap = new HashMap<>();
//在靜態塊中先把初始化工作全部做完
static {
role0perationMap.put( "ROLE_ ROOT_ ADMIN",new RootAdminRole("ROLE_ _ROOT_ ADMIN") ) :
roleOperationMap.put( "ROLE_ ORDER_ ADMIN",new OrderAdminRole("ROLE_ ORDER_ ADMIN") );
role0perationMap.put( "ROLE_ NORMAL",new NormalRole("ROLE_ NORMAL") );
}
pub1ic static RoleOperation getOp( String roleName ) {
return roleOperationMap.get( roleName ) ;
}
}
接下來藉助上面這個工廠，業務程式碼呼叫也只需一行程式碼， if/else同樣被消除了：
public class JudgeRole {
public String judge(String roleName){
//一行程式碼搞定! 之前的if/else也沒了!
return RoleFactory.get0p(roleName).op();
}
}
這樣的話以後想擴充套件條件也很容易，只需要增加新程式碼，而不需要動以前的業務程式碼，非常符合“開閉原則”。
到此這篇關於嘁,都2020了,你咋還在單純的使用if-else的文章就介紹到這了,更多相關if-else使用內容請搜尋我們以前的文章或繼續瀏覽下面的相關文章希望大家以後多多支援我們！