在程式人員的日常工作中，似乎經常無法避免用到大量的參數。長遠來看，大量參數會導致method難以維護和重利用。重構方法 - Introduce Parameter Object，就是用來保持介面簡單的方式。可以參考搞笑談軟工 ：用Introduce Parameter Object移除Long Parameter List怪味道。
介面簡短的方法能夠維持簡單的上下文，因而更容易被人理解。從某個意義來說，介面長短與程式碼單元(method)的尺寸和複雜度有關係。如果你的方法包含8個參數(舉例來說)，以及處理8個參數的程式碼，你就很難將它拆分成多個獨立的部分。
冗長介面通常不是主要問題，而是真實問題的表徵-意味著糟糕透頂的資料模型
如何遵守此指導方針
介面應該簡短到甚麼程度?將參數個數上限設為 4 是比較合理的(作者沒有說為什麼)。
透過重構方法Introduce Parameter Object將參數包裝成參數物件(parameter object)，或稱做DTO(data transfer object)，這些物件實際上代表對應的Domain的重要概念。例如：一組點座標、一個矩形。封裝這些 類別並不只是減少方法參數的個數，還有可能將一些行為搬到該類別上，讓邏輯更集中更乾淨。
常見的反對意見
試著反向思考這個問題
參數物件具有龐大的介面
「我所引進之參數物件的建構式現在擁有太多參數」
如果遇到這種情況，通常意味著需要在該物件內部進行更細緻的劃分。
重構冗長介面並未改善我的情況
「在重構方法時，我還是把大量參數傳遞給另一個方法」
避免冗長介面並非總是一件容易的事，通常不單靠重構的某一個方法。作者建議，應該持續將不同職責拆分到各個方法去。
Framework或Library已經定義了具有冗長參數列的介面
「在我們正在使用的框架中，某些介面具有9個參數。如何在不違反介面指導方針的情況下實作它們呢?」
作者承認這是不容易的事，只能盡量限制住它們的衝擊。作者建議用Adapter Pattern去隔離它。