手裡拿著錘子，看啥都像釘子

老師，提乙個問題，在實際生活中遇到的 比如說我寫了乙個傳送訊息的方法。比如說有乙個引數是 messagedto，但是他有很多屬性，比如說 topic，tag，shadingkey，msg， delaytime 等等，但是我希望別人在使用這個方法的時候傳入 messagedto 是我想要的，即我會將無參構造方法私有化，因為我不想讓別人使用無參構造new乙個物件出來，（因為自己去set可能某一些引數設定有遺漏），然後只限制了 幾種建構函式，或者使用靜態方法來建立物件。

然後物件的入參是由要求的。比如說你想法 普通資訊，那麼需要 topic和msg，發延遲訊息，需要topic msg和delaytime，發順序訊息需要額外再加乙個shadingkey，請問在這種情況下如何使用建造者模式。即只允許使用某一組引數來建立物件

雖然我們學了建造者模式，未必一定要用建造者模式。

針對這種場景，有很多方法可以更優雅地實現：

messagefactory類

構造普通資訊

public

static messagedto buildcommonmsg
(string topic, string msg)

public

static messagedto builddelaymsg
(string topic, string msg,long delaytime)

public

static messagedto buildorderedmsg
(string topic, string msg, string shadingkey)

普通資訊 commonmsgdto

public

class
commonmsgdto

public

class
delaymsgdto
extends
commonmsgdto

public

class
orderedmsgdto
extends
commonmsgdto

如果傳 null 可以報錯。

public

static
class
builder
// 其他屬性的set 方法
}

這樣必備屬性必然會傳入。

但是如果必傳引數太多，不推薦使用這種方式。

哪怕是不同的 builder 模式，在 build時進行引數校驗。

可能還有很多解決方案，上面給出兩個比較簡單且常見的方法。

在執行傳送訊息的函式上加上引數校驗，這樣就不容易出錯。

希望大家一定要破除 」手裡拿著錘子，看啥都像釘子「的心理。

在學習任何技術時，思考其最適合的場景，為了解決什麼問題，侷限是什麼。

在解決問題前想清楚問題是什麼？

比如這位同學核心是為了能讓使用者清晰地區分型別，然後讓使用者知道不同型別的引數差異。

然後再去思考怎樣更容易區分開呢？必傳引數一定要早構造的時候校驗嗎？

慢慢地，問題就明了了，就更容易得到更科學的答案。

總之，既要埋頭苦學，又要抬頭看路。學而不思則罔！

如果想在開發中少趟坑，感興趣可以看看我最近出的幾個 gitchat:

程式設計師的創業 手裡有個錘子，看什麼都像釘子

愛乙個人，就讓他去創業 恨乙個人，也讓他去創業。所有人都盼著國慶節，但正在創業的人除外。程式設計師老是吼什麼加班，但我那麼幾個老碼農的qq群騙不了人 上班時間各種嗨，一到下班時間，冷火煙清的沒人了。國慶節這幾個qq群幾乎沒動靜，但另外幾個創業 一樣的熱鬧。有人問，創業和打工最大的區別是什麼？反正就我...