運用Extract Method處理上述范例
面對上代碼,我通常不會以臨時變量來解釋其動作意圖,我更喜歡使用Extract Method(110).讓我們回到起點:
double price() {
//price is base price - quantity discount + shipping
return _quantity * _itemPrice -
Math.max(0, _quantity - 500) * _itemPrice * 0.05 +
Math.min(_quantity * _itemPrice * 0.1, 100.0);
}
這次我把底價計算提煉到一個獨立函數中:
double price() {
//price is base price - quantity discount + shipping
return basePrice() -
Math.max(0, _quantity - 500) * _itemPrice * 0.05 +
Math.min(basePrice() * 0.1, 100.0);
}
private double basePrice() {
return _quantity * _itemPrice;
}
我繼續我的提煉,每次提煉出一個新函數.最后得到下列代碼:
double price() {
//price is base price - quantity discount + shipping
return basePrice() - quantityDiscount() + shipping();
}
private double quantityDiscount() {
Math.max(0, _quantity - 500) * _itemPrice * 0.05;
}
private double shipping() {
Math.min(basePrice() * 0.1, 100.0);
}
private double basePrice() {
return _quantity * _itemPrice;
}
我比較喜歡使用Extract Method(110),因為同一對象中的任何部分,都可以根據自己的需要去取用這些提煉出來的函數.一開始我會這些新函數聲明為private;如果其他對象也需要它們,我可以輕易釋放這些函數的訪問限制.我還發現,Extract Method(110)的工作量通常并不必Introduce Explaining Variable(124)來得大.
那么,應該在什么時候使用Introduce Explaining Variable(124)呢?答案是:在Extract Method(110)需要花費更大工作量時.如果我要處理的是一個擁有大量局部變量的算法,那么使用Extract Method(110)絕非易事.這種情況下我會使用Introduce Explaining Variable(124)幫助我清理代碼,然后再考慮下一步該怎么辦.搞清楚代碼邏輯之后,我總是可以運用Replace Temp with Query(120)把被我引入的那些解釋性臨時變量去掉.況且,如果我最終使用Replace Method with Method Object(135),那么被我引入的那些解釋性臨時變量也有其價值.