小弟有這樣一個(gè)方法，按頁(yè)大小和頁(yè)索引查詢產(chǎn)品，如下。

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

可以看到小弟這個(gè)方法參數(shù)比較多，有7個(gè)，這時(shí)有人就說(shuō)了:“這么多參數(shù)，應(yīng)該封裝成一個(gè)對(duì)象傳遞！”要寫成下面這個(gè)樣子。

public class QueryProduct
{
private int? manufacturerID;

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

private int? categoryID;

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

private int? typeID;

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

private string name;

/// <summary>
/// 產(chǎn)品名稱，模糊匹配。
/// </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>
/// 頁(yè)大小
/// </summary>
public int PageSize
{
get { return pageSize; }
set { pageSize = value; }
}

private int pageIndex;

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

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

小弟心里就想了 ，這才幾個(gè)參數(shù)，連10個(gè)都不到，封裝成一個(gè)對(duì)象有必要嗎？

下面是各自對(duì)問(wèn)題的看法

應(yīng)該封裝成對(duì)象：
1.不封裝成對(duì)象，代碼看起來(lái)很亂。
2.可維護(hù)性強(qiáng)，以后這個(gè)方法如果需要加查詢參數(shù)，只需要在QueryProduct類中增加一個(gè)屬性即可，方法不用改。
3.方法的參數(shù)越少越好，能少一個(gè)，絕不多一個(gè)。
4.方法的參數(shù)超過(guò)3個(gè)就要封裝成對(duì)象。

應(yīng)該直接傳遞參數(shù)：
1.直接將查詢條件寫在方法參數(shù)上，可讀性強(qiáng)，便于后來(lái)人維護(hù)。
2.封裝成對(duì)象，項(xiàng)目中就需要增加一個(gè)對(duì)象，對(duì)象越多，越不利于維護(hù)，10個(gè)以內(nèi)的參數(shù)，如果沒(méi)有特殊原因，不需要封裝成對(duì)象。
3.這里的參數(shù)每一個(gè)都有業(yè)務(wù)意義，并不是要持久化到數(shù)據(jù)庫(kù)的實(shí)體屬性，在數(shù)量不多的時(shí)候，不應(yīng)該封裝成對(duì)象。

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

關(guān)于這個(gè)問(wèn)題，小弟希望看看大家是怎么對(duì)待的，希望大家能在回復(fù)時(shí)除了表述自己的觀點(diǎn)，同時(shí)告知在項(xiàng)目中會(huì)采取哪種方式。

轉(zhuǎn)載于:https://www.cnblogs.com/aaronyu/archive/2011/07/12/2104353.html

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。