嘁,都2020了,你咋還在單純的使用if-else?

在高級語言中,基本上都提供了像if-elseswitch-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簡直具有了“壞”代碼具有的一切:

  1. 數據和實現邏輯強耦合
  2. 擴展麻煩,維護性低

改善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,30,31,31,30,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那樣“輕鬆”,我們需要先思考兩個問題:

  1. 如何從表中查詢數據?如果if-else判斷的是範圍,該怎麼查?
  2. 查什麼?(數據?索引?)

基於這兩個問題,有人將依據表驅動的查詢分爲三種:

  1. 直接訪問
  2. 索引訪問
  3. 階梯訪問

1、直接訪問表
筆者最近按照母親的“旨意”跑了一趟保險公司,發現這個保險費率非常麻煩——它會根據年齡、性別、婚姻狀態等不同情況變化。看着上面輸出日期的程序想一下,如果你用邏輯控制解構(if or switch)來表示不同費率,那會有多麻煩!(事實上,你的代碼可能會像八爪魚一樣…)

我們能夠知道,這裏的【年齡】是個範圍!沒法用數組或者對象來做映射。這有兩種解決方案:直接訪問表 or 階梯訪問表。筆者決定先試試“直接訪問表”的方式,並找到了兩種方法:

  1. 複製信息從而能夠直接使用鍵值:我們可以給 1-17 年齡範圍的每個年齡都複製一份信息,然後直接用 age 來訪問,同理對其他年齡段的也都一樣。這種方法在於操作很簡單,表的結構也很簡單。但有個缺點就是會浪費空間,畢竟生成了很多冗餘信息。(不建議使用)
  2. 轉換鍵值,如果我們把年齡範圍轉換成鍵呢?這樣就可以直接來訪問了,唯一需要考慮的問題就是有些情境下年齡如何轉換爲鍵值。

對於第二種方法,有人可能疑惑了:還要用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',...'18-65','18-65','18-65',...'>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();
	}
}

這樣的話以後想擴展條件也很容易,只需要增加新代碼,而不需要動以前的業務代碼,非常符合“開閉原則”。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章