小弟有這樣一個方法，按頁大小和頁索引查詢產品，如下。

/// <summary>
/// 獲取產品
/// </summary>
/// <param name="manufacturerID">廠商ID，為null時不做查詢條件。</param>
/// <param name="categoryID">類別ID，為null時不做查詢條件。</param>
/// <param name="typeID">類型ID，為null時不做查詢條件。</param>
/// <param name="name">產品名稱，模糊匹配。</param>
/// <param name="description">描述，模糊匹配。</param>
/// <param name="pageSize">頁大小</param>
/// <param name="pageIndex">頁索引</param>
/// <returns></returns>
public DataTable GetProduct(int? manufacturerID, int? categoryID, int? typeID, string name, string description, int pageSize, int pageIndex)
{
return null;
}

可以看到小弟這個方法參數比較多，有7個，這時有人就說了:“這么多參數，應該封裝成一個對象傳遞！”要寫成下面這個樣子。

public class QueryProduct
{
private int? manufacturerID;

/// <summary>
/// 廠商ID，為null時不做查詢條件。
/// </summary>
public int? ManufacturerID
{
get { return manufacturerID; }
set { manufacturerID = value; }
}

private int? categoryID;

/// <summary>
/// 類別ID，為null時不做查詢條件。
/// </summary>
public int? CategoryID
{
get { return categoryID; }
set { categoryID = value; }
}

private int? typeID;

/// <summary>
/// 類型ID，為null時不做查詢條件。
/// </summary>
public int? TypeID
{
get { return typeID; }
set { typeID = value; }
}

private string name;

/// <summary>
/// 產品名稱，模糊匹配。
/// </summary>
public string Name
{
get { return name; }
set { name = value; }
}

private string description;

/// <summary>
/// 描述，模糊匹配。
/// </summary>
public string Description
{
get { return description; }
set { description = value; }
}

private int pageSize;

/// <summary>
/// 頁大小
/// </summary>
public int PageSize
{
get { return pageSize; }
set { pageSize = value; }
}

private int pageIndex;

/// <summary>
/// 頁索引
/// </summary>
public int PageIndex
{
get { return pageIndex; }
set { pageIndex = value; }
}
}

/// <summary>
/// 獲取產品
/// </summary>
/// <param name="query">查詢條件</param>
/// <returns></returns>
public DataTable GetProduct(QueryProduct query)
{
return null;
}

小弟心里就想了 ，這才幾個參數，連10個都不到，封裝成一個對象有必要嗎？

下面是各自對問題的看法

應該封裝成對象：
1.不封裝成對象，代碼看起來很亂。
2.可維護性強，以后這個方法如果需要加查詢參數，只需要在QueryProduct類中增加一個屬性即可，方法不用改。
3.方法的參數越少越好，能少一個，絕不多一個。
4.方法的參數超過3個就要封裝成對象。

應該直接傳遞參數：
1.直接將查詢條件寫在方法參數上，可讀性強，便于后來人維護。
2.封裝成對象，項目中就需要增加一個對象，對象越多，越不利于維護，10個以內的參數，如果沒有特殊原因，不需要封裝成對象。
3.這里的參數每一個都有業務意義，并不是要持久化到數據庫的實體屬性，在數量不多的時候，不應該封裝成對象。

下面是小弟對“應該封裝成對象”一派3個理由的回復
1.不封裝成對象，代碼看起來很亂。
一點都不亂，封裝成對象反倒增加了閱讀成本。
2.可維護性強，以后這個方法如果需要加查詢參數，只需要在QueryProduct類中增加一個屬性即可，方法不用改。
可維護性絕對沒有增強，反倒因為項目中多了一堆查詢條件對象，增加了閱讀成本，降低了維護性。當增加查詢條件時，改了查詢對象的定義，方法的參數就變了，方法也100%的變了，只是方法的代碼沒改，但方法的定義已經改了，這完全沒有優勢。都是改代碼，都是改方法的參數，都改變了方法的定義。
3.方法的參數越少越好，能少一個，絕不多一個。
這里沒有一個參數是多余的，少任何一個參數都不能滿足需求，方法的參數越少越好是毋庸置疑的，但絕不是用這種坑爹的方式減少參數。
4.方法的參數超過3個就要封裝成對象。
是否要將參數封裝成對象，不能只看參數的數量，還要看它的業務意義，作為數據載體的實體類，即使只有兩個屬性，也要用對象傳遞。但像這種，不需要持久化，而且每個參數都有各自的業務意義，沒有特殊原因，就應該寫在方法的參數列表里。

關于這個問題，小弟希望看看大家是怎么對待的，希望大家能在回復時除了表述自己的觀點，同時告知在項目中會采取哪種方式。

轉載于:https://www.cnblogs.com/aaronyu/archive/2011/07/12/2104353.html

總結

以上是生活随笔為你收集整理的方法有多少个参数才算多？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。