### Remove Assignments to Parameters(移除對參數的賦值動作)
你的代碼對一個參數進行賦值動作。
以一個臨時變量取代該參數的位置。
~~~
int discount (int inputVal, int quantity, int yearToDate) {
if (inputVal > 50) inputVal -= 2;
~~~
=>
~~~
int discount (int inputVal, int quantity, int yearToDate) {
int result = inputVal;
if (inputVal > 50) result -= 2;
~~~
**動機(Motivation)**
首先,我要確定大家都清楚「對參數賦值」這個說法的意思。如果你把一個名為foo 的對象作為參數傳給某個函數,那么「對參數賦值」意味改變foo,使它引用(參考、指涉、指向)另一個對象。如果你在「被傳入對象」身上進行什么操作,那沒問題,我也總是這樣干。我只針對「foo被改而指向(引用)完全不同的另一個對象」這種情況來討論:
~~~
void aMethod(Object foo) {
foo.modifyInSomeWay(); // that's OK
foo = anotherObject; // trouble and despair will follow you
~~~
我之所以不喜歡這樣的作法,因為它降低了代碼的清晰度,而且混淆了 pass by value(傳值〕和 pass by reference (傳址)這兩種參數傳遞方式。Java只采用 pass by value傳遞方式(稍后討論),我們的討論也正是基于這一點。
在 pass by value情況下,對參數的任何修改,都不會對調用端造成任何影響。那些用過 pass by reference的人可能會在這一點上犯糊涂。
另一個讓人糊涂的地方是函數本體內。如果你只以參數表示「被傳遞進來的東西」,那么代碼會清晰得多,因為這種用法在所有語言中都表現出相同語義。
在Java中,不要對參數賦值;如果你看到手上的代碼已經這樣做了,請使用Remove Assignments to Parameters。
當然,面對那些使用「輸出式參數」( output parameters)的語言,你不必遵循這條規則。不過在那些語言中我會盡量少用輸出式參數。
**作法(Mechanics)**
- 建立一個臨時變量,把待處理的參數值賦予它。
- 以「對參數的賦值動作」為界,將其后所有對此參數的引用點,全部替換為「對此臨時變量的引用動作」。
- 修改賦值語句,使其改為對新建之臨時變量賦值。
- 編譯,測試。
- 如果代碼的語義是 pass by reference,請在調用端檢查調用后是否還使用了這個參數。也要檢查有多少個 pass by reference參數「被賦值后又被使用」。請盡量只以return方式返回一個值。如果需要返回的值不只一個,看看可否把需返回的大堆數據變成單一對象,或千脆為每個返回值設計對應的一個獨立函數。
**范例(Example)**
我從下列這段簡單代碼開始:
~~~
int discount (int inputVal, int quantity, int yearToDate) {
if (inputVal > 50) inputVal -= 2;
if (quantity > 100) inputVal -= 1;
if (yearToDate > 10000) inputVal -= 4;
return inputVal;
}
~~~
以臨時變量取代對參數的賦值動作,得到下列代碼:
~~~
int discount (int inputVal, int quantity, int yearToDate) {
int result = inputVal;
if (inputVal > 50) result -= 2;
if (quantity > 100) result -= 1;
if (yearToDate > 10000) result -= 4;
return result;
}
~~~
還可以為參數加上關鍵詞final,從而強制它遵循「不對參數賦值」這一慣例:
~~~
int discount (final int inputVal, final int quantity, final int yearToDate) {
int result = inputVal;
if (inputVal > 50) result -= 2;
if (quantity > 100) result -= 1;
if (yearToDate > 10000) result -= 4;
return result;
}
~~~
不過我得承認,我并不經常使用final來修飾參數,因為我發現,對于提高短函數的清晰度,這個辦法并無太大幫助。我通常會在較長的函數中使用它,讓它幫助我檢查參數是否被做了修改。
**Java的pass by value(傳值)**
Java使用"pass by value"「函數調用」方式,這常常造成許多人迷惑。在所有地點,Java都嚴格釆用pass by value,所以下列程序:
~~~
class Param {
public static void main(String[] args) {
int x = 5;
triple(x);
System.out.println ("x after triple: " + x);
}
private static void triple(int arg) {
arg = arg * 3;
System.out.println ("arg in triple: " + arg);
}
}
~~~
會產生這樣的輸出:
~~~
arg in triple: 15
x after triple: 5
~~~
這段代碼還不至于讓人糊涂。但如果參數中傳遞的是對象,就可能把人弄迷糊了。如果我在程序中以Date對象表示日期,那么下列程序:
~~~
class Param {
public static void main(String[] args) {
Date d1 = new Date ("1 Apr 98");
nextDateUpdate(d1);
System.out.println ("d1 after nextDay: " + d1);
Date d2 = new Date ("1 Apr 98");
nextDateReplace(d2);
System.out.println ("d2 after nextDay: " + d2);
}
private static void nextDateUpdate (Date arg) {
arg.setDate(arg.getDate() + 1);
System.out.println ("arg in nextDay: " + arg);
}
private static void nextDateReplace (Date arg) {
arg = new Date (arg.getYear(), arg.getMonth(), arg.getDate() + 1);
System.out.println ("arg in nextDay: " + arg);
}
}
~~~
產生的輸出是:
~~~
arg in nextDay: Thu Apr 02 00:00:00 EST 1998
d1 after nextDay: Thu Apr 02 00:00:00 EST 1998
arg in nextDay: Thu Apr 02 00:00:00 EST 1998
d2 after nextDay: Wed Apr 01 00:00:00 EST 1998
~~~
從本質上說,object reference是按值傳遞的(passed by value)。因此我可以修改參數對象的內部狀態,但對參數對象重新賦值,沒有意義。
Java1.1及其后版本,允許你將參數標示為final,從而避免函數中對參數賦值。 即使某個參數被標示為final,你仍然可以修改它所指向的對象。我總是把參數視為final,但是我得承認,我很少在參數列(parameter list)中這樣標示它們。
- 譯序 by 侯捷
- 譯序 by 熊節
- 序言
- 前言
- 章節一 重構,第一個案例
- 起點
- 重構的第一步
- 分解并重組statement()
- 運用多態(Polymorphism)取代與價格相關的條件邏輯
- 結語
- 章節二 重構原則
- 何謂重構
- 為何重構
- 「重構」助你找到臭蟲(bugs)
- 何時重構
- 怎么對經理說?
- 重構的難題
- 重構與設計
- 重構與性能(Performance)
- 重構起源何處?
- 章節三 代碼的壞味道
- Duplicated Code(重復的代碼)
- Long Method(過長函數)
- Large Class(過大類)
- Long Parameter List(過長參數列)
- Divergent Change(發散式變化)
- Shotgun Surgery(散彈式修改)
- Feature Envy(依戀情結)
- Data Clumps(數據泥團)
- Primitive Obsession(基本型別偏執)
- Switch Statements(switch驚悚現身)
- Parallel Inheritance Hierarchies(平行繼承體系)
- Lazy Class(冗贅類)
- Speculative Generality(夸夸其談未來性)
- Temporary Field(令人迷惑的暫時值域)
- Message Chains(過度耦合的消息鏈)
- Middle Man(中間轉手人)
- Inappropriate Intimacy(狎昵關系)
- Alternative Classes with Different Interfaces(異曲同工的類)
- Incomplete Library Class(不完美的程序庫類)
- Data Class(純稚的數據類)
- Refused Bequest(被拒絕的遺贈)
- Comments(過多的注釋)
- 章節四 構筑測試體系
- 自我測試代碼的價值
- JUnit測試框架
- 添加更多測試
- 章節五 重構名錄
- 重構的記錄格式
- 尋找引用點
- 這些重構準則有多成熟
- 章節六 重新組織你的函數
- Extract Method(提煉函數)
- Inline Method(將函數內聯化)
- Inline Temp(將臨時變量內聯化)
- Replace Temp with Query(以查詢取代臨時變量)
- Introduce Explaining Variable(引入解釋性變量)
- Split Temporary Variable(剖解臨時變量)
- Remove Assignments to Parameters(移除對參數的賦值動作)
- Replace Method with Method Object(以函數對象取代函數)
- Substitute Algorithm(替換你的算法)
- 章節七 在對象之間搬移特性
- Move Method(搬移函數)
- Move Field(搬移值域)
- Extract Class(提煉類)
- Inline Class(將類內聯化)
- Hide Delegate(隱藏「委托關系」)
- Remove Middle Man(移除中間人)
- Introduce Foreign Method(引入外加函數)
- Introduce Local Extension(引入本地擴展)
- 章節八 重新組織數據
- Self Encapsulate Field(自封裝值域)
- Replace Data Value with Object(以對象取代數據值)
- Change Value to Reference(將實值對象改為引用對象)
- Replace Array with Object(以對象取代數組)
- Replace Array with Object(以對象取代數組)
- Duplicate Observed Data(復制「被監視數據」)
- Change Unidirectional Association to Bidirectional(將單向關聯改為雙向)
- Change Bidirectional Association to Unidirectional(將雙向關聯改為單向)
- Replace Magic Number with Symbolic Constant(以符號常量/字面常量取代魔法數)
- Encapsulate Field(封裝值域)
- Encapsulate Collection(封裝群集)
- Replace Record with Data Class(以數據類取代記錄)
- Replace Type Code with Class(以類取代型別碼)
- Replace Type Code with Subclasses(以子類取代型別碼)
- Replace Type Code with State/Strategy(以State/strategy 取代型別碼)
- Replace Subclass with Fields(以值域取代子類)
- 章節九 簡化條件表達式
- Decompose Conditional(分解條件式)
- Consolidate Conditional Expression(合并條件式)
- Consolidate Duplicate Conditional Fragments(合并重復的條件片段)
- Remove Control Flag(移除控制標記)
- Replace Nested Conditional with Guard Clauses(以衛語句取代嵌套條件式)
- Replace Conditional with Polymorphism(以多態取代條件式)
- Introduce Null Object(引入Null 對象)
- Introduce Assertion(引入斷言)
- 章節十一 處理概括關系
- Pull Up Field(值域上移)
- Pull Up Method(函數上移)
- Pull Up Constructor Body(構造函數本體上移)
- Push Down Method(函數下移)
- Push Down Field(值域下移)
- Extract Subclass(提煉子類)
- Extract Superclass(提煉超類)
- Extract Interface(提煉接口)
- Collapse Hierarchy(折疊繼承關系)
- Form Template Method(塑造模板函數)
- Replace Inheritance with Delegation(以委托取代繼承)
- Replace Delegation with Inheritance(以繼承取代委托)
- 章節十二 大型重構
- 這場游戲的本質
- Tease Apart Inheritance(梳理并分解繼承體系)
- Convert Procedural Design to Objects(將過程化設計轉化為對象設計)
- Separate Domain from Presentation(將領域和表述/顯示分離)
- Extract Hierarchy(提煉繼承體系)
- 章節十三 重構,復用與現實
- 現實的檢驗
- 為什么開發者不愿意重構他們的程序?
- 現實的檢驗(再論)
- 重構的資源和參考資料
- 從重構聯想到軟件復用和技術傳播
- 結語
- 參考文獻
- 章節十四 重構工具
- 使用工具進行重構
- 重構工具的技術標準(Technical Criteria )
- 重構工具的實用標準(Practical Criteria )
- 小結
- 章節十五 集成
- 參考書目