英文原文鏈接：https://www.gustavwengel.dk/csharp-static-factory-vs-constructor?utm_source=csharpdigest&utm_medium=email&utm_campaign=299

最近，在與同事進行協(xié)同編程時，我們開始討論在C#中初始化新對象的最佳方法。我一直是使用構(gòu)造函數(shù)實現(xiàn)，盡管他傾向于靜態(tài)工程方法。這引起了關(guān)于每種類型的利弊的大量來來回回的討論。

為了說明我所說的內(nèi)容，這是兩個例子：

// Using the constructor
SqlConnection myConnection = new SqlConnection(connectionString);
// Using a static factory method
IDbConnection myConnection = SqlConnection.FromConnectionString(connectionString);

之前我從未考慮過實現(xiàn)這些靜態(tài)工廠方法，我并自嘲問不了解其內(nèi)容。自從那以后，我改變了注意，讓我們深入探討其優(yōu)缺點。

靜態(tài)工廠方法的優(yōu)點

無須返回一個新的實例

而構(gòu)造函數(shù)總是返回一個新的對象。

當(dāng)新對象創(chuàng)建失敗時，你不能使用一個緩存的對象或返回 null。特別是在編寫庫代碼時，將來可能會很靈活。

你可以使用方法參考

如果你傾向于以一種實用的方式編寫C#，你可能會感激你可以在代碼中傳遞該方法（或正式稱為“方法組”）的引用。對比一下：

// Static factory method - the method group can be passed in directly as a function reference
var bars = myFoo.Select(bar.FromFoo)

// Constructors - you have to pass in a lambda that constructs the instance via new.
var bars = myFoo.Select(f => new Bar(f));

這段代碼沒有功能上的差異，只是代碼風(fēng)格上的一個問題。因此可能不應(yīng)在決策中過分重視。

你能通過名字了解

對于某些對象，尤其是可以通過多種類似方式構(gòu)造的對象-能夠在構(gòu)造對象的方式上獲益良多。讓我們以Color類為例，該類可以通過CMYK和RGB參數(shù)構(gòu)造。

// With constructors
var color = new Color(25, 25, 5, 80);
var color = new Color(100, 150, 50);

// With static factory methods
var color = Color.FromCMYK(25, 25, 5, 80);
var color = Color.FromRGB(100, 150, 50);

與更具描述性的靜態(tài)工程方法進行對比，除非你知道Color的四個值的構(gòu)造函數(shù)是CMYK，三個值的構(gòu)造函數(shù)是RGB，否則無法通過閱讀代碼來區(qū)別出來。

我認為，如果你有不同的構(gòu)造對象的方式，尤其是參數(shù)彼此相似的方式，有很充分的理由來使用靜態(tài)工廠方法。

工廠方法可以返回不同的類

newFoo()總是返回一個 Foo類的一個新的實例， Foo.FromBar很容易的返回一個 IFoo接口，或者 Foo的一個子類。一個可能與之相關(guān)的真實示例：

// This could create an IpV4IpAddress that implements IIpAddress
IIpAddress ipv4Address = IpAddress.FromString("127.0.0.1");

// This could create an IpV6IpAddress that implements IIpAddress
IIpAddress ipv6Address = IpAddress.FromString("2001:0db8:0a0b:12f0:0000:0000:0000:0001")

在提供公共API（例如在庫上下文中）時，能夠根據(jù)輸入返回不同的實際類型可能非常有價值。特別是因為這意味著你可以在接口或者基類后面隱藏一些實現(xiàn)細節(jié)。

我不確定應(yīng)用程序代碼中的價值是否一樣大，你可以在其中控制整個庫代碼，并使大規(guī)模重構(gòu)變得更加容易。

在構(gòu)造函數(shù)中你不應(yīng)該做的事情

通常，人們并不期望構(gòu)造函數(shù)除了構(gòu)造對象之外，還能做其他很多事情。盡管你可以在構(gòu)造函數(shù)中執(zhí)行I/O，數(shù)據(jù)庫訪問等操作，但大多數(shù)人并不期望這樣做。按照慣例，你可以自由的以靜態(tài)工廠方法執(zhí)行更多的工作，而無需任何人引起注意。

有些人也不認為你應(yīng)該在構(gòu)造函數(shù)中拋出異常。也許這取決于語言，但在C#中完全可以，如果要在構(gòu)造函數(shù)中創(chuàng)建非托管資源，請注意以下幾點。

靜態(tài)工廠方法的缺點

在構(gòu)造函數(shù)中不應(yīng)該做的事情

按照慣例，構(gòu)造函數(shù)通常更簡單。當(dāng)我調(diào)用構(gòu)造函數(shù)時，通常不希望它執(zhí)行I/O或其他。這使構(gòu)造函數(shù)的構(gòu)造靈活性大大降低，這既是福也是禍。

意味著更多代碼

無論如何，你仍然需要構(gòu)造函數(shù)來實際構(gòu)造對象。靜態(tài)工廠方法是更多的代碼，而代碼是一種責(zé)任。它通常不是很復(fù)制的代碼，并且通常靜態(tài)工廠方法也不是特別長，因此這可能不是一個很大的缺點。

很難找到

通常，當(dāng)我嘗試構(gòu)造一個新對象時，我會先尋找構(gòu)造函數(shù)。通過自動完成功能很難找到靜態(tài)方法，因為他們通常無法與其他靜態(tài)方法區(qū)分開。

我認為靜態(tài)方法最大的問題是你失去了可發(fā)現(xiàn)性。

經(jīng)過研究和思考之后，我認為我目前的看法是：

你應(yīng)該始終創(chuàng)建一個構(gòu)造函數(shù)，該構(gòu)造函數(shù)將1:1映射到類內(nèi)部的字段
如果你需要花很多時間來創(chuàng)建對象（例如IO），或者對緩存對象并重新使用它們感興趣，請使用靜態(tài)工廠方法。
如果你需要API穩(wěn)定(例如用于庫開發(fā)),請隱藏該構(gòu)造函數(shù)并使用靜態(tài)工廠方法,因為它為你提供了實現(xiàn)的靈活性。
如果你有多種不同的方法來創(chuàng)建類,請創(chuàng)建靜態(tài)工廠方法并使用它們,因為它們?yōu)槟闾峁┝嗣鑼懶浴?/span>

C#的靜態(tài)工廠方法與構(gòu)造函數(shù)對比