現在回到重構--改善既有代碼的設計這本書。
3.4Long Parameter List（過長參數列）
如果“向既有對象發出一條請求”就可以取得原本位于參數列上的一份數據，那么你應該激活重構準則Replace Parameter with Method。上述的既有對象可能是函數所屬class內的一個值域，也可能是另一個參數。你還可以用 Preserve Whole Object將來自同一對象的一堆數據收藏起來，并以該對象替換它們。如果某些數據缺乏合理的對象歸屬，可使用Introduce Parameter Object為它們制造出一個“參數對象”。

Replace Parameter with Methods(以函數取代參數)
對象調用某個函數，并將結果作為參數，傳遞給另外一個函數。而接受該參數的函數也可以（也有能力）調用前一個函數。
動機
如果函數可以通過其它途徑（而非參數列）獲得參數值，那么它就不應該通過參數取得該值。
縮減參數列的辦法之一就是，看看“參數接受端”是否可以通過“與調用端相同的計算”來取得參數攜帶值。如果調用端通過“其所屬對象內部的另一個函數”來計算參數，并在計算過程中“未曾飲用調用端的其它參數”，那么你就應該將這個計算過程轉移到被調用端內，從而除去該項參數。如果你所調用的函數隸屬另一對象，而該對象擁有一個reference指向調用端所屬對象，前面所說的這些也同樣適用。
作法
1、如果有必要，將參數的計算過程提煉到一個獨立函數中。
2、將函數本體內“對該參數的引用”替換為對“新函數的引用”。
3、每次替換后，修改并測試。
4、全部替換完成后，適用Remove Parameter將該參數去掉。

---

思考：
確實從實踐角度講，上面這種方法是一種很實用的重構方法。確實是縮減了函數的參數個數，并隱藏了一些中間結果。但是我認為，在應用這個方法的時候，還應當考慮這樣兩個問題：
1、當中間函數（方法）被隱藏的時候，以這個中間函數的返回值為參數的那個函數名還能夠表述自己的用途嗎？
2、被修改的那個函數所處的具體語境是什么。因為在面向對象編程的時代，單獨去考慮一個函數的情況是很少的。確保這個函數是否處在正確的位置上（如是否處在正確的類中）是必要的。

---

此間存在一個重要的例外。有時候你明顯不希望造成“被調用之對象”與“較大對象”間的某種依存關系。這時候將數據從對象拆解出來單獨作為參數，也很合情合理。但是請注意其所引發的代價。如果參數列太長或變化太頻繁，你就需要重新考慮自己的依存結構了。

 Introduce Parameter Object（引入參數對象）
某些參數總是很自然的同時出現，以一個對象取代這些參數。
你常會看到特定的一組參數總是一起被傳遞。可能有好幾個函數都使用這一組參數，這些函數可能隸屬同一個class，也可能隸屬不同的classes。這樣一組參數就是所謂的Data Clump(數據泥團)。我們可以運用一個對象包裝所有這些數據，再以該對象取代它們。
作法：
1、新建一個class，用以表現你想替換的一組參數。將這個class設為不可變的(不可被修改的，immutable)。
2、編譯。
3、針對使用該組參數的所有函數，實施Add Parameter，以上述新建class之實體對象作為新添參數，并將此一參數值設為null。
4、對于Data Clump(數據泥團)中的每一項(在此均為參數)，從函數簽名式中移除之，并修改調用端和函數本體，令他們都改而通過“新建的參數對象” 取得該值。
5、每除去一個參數，編譯并測試。
6、將原先的參數全部除去之后，觀察有無適當函數可以運用Move Method搬移到參數對象中。

---

思考：
現在我有一個函數f，函數定義如下：
public string f(int i,int j,string s)
{
   int newValue=i+j;
   string result=s+":"+newValue.ToString();
   return result;
}
現在我把這三個參數轉化為類對象，類名定義為MyParameter

然后再我的代碼中這樣寫：
f(new MyParameter(3,2,"Result"));

發現什么問題了嗎？
1、好像參數并沒有減少，只不過是移動到了構造函數中；
2、你從f參數中將會看不出f中到底需要什么東西（如果參數名稱體現了參數的用途的話）。
這說明：
1、雖然這是經典的重構方法，但是不能濫用，在使用的時候要謹慎考慮場景是否合適。
2、注意TDA原理，不要刻意產生太多的中間對象。
3、參數不能隨便合并或隱去，要特別注意領域模型，要切合領域模型所表述的意圖。
我個人認為可以應用的場景：
就是文中所說的DataRange，即適合于被轉換為參數對象的參數列具有通用的含義，并且概念層次比較低。

---