最近，在與同事進行協同編程時，我們開始討論在C#中初始化新對象的最佳方法。我一直是使用構造函數實現，儘管他傾向於靜態工程方法。這引起了關於每種類型的利弊的大量來來回回的討論。
爲了說明我所說的內容，這是兩個例子：
// Using the constructor
SqlConnection myConnection = new SqlConnection(connectionString);
// Using a static factory method
IDbConnection myConnection = SqlConnection.FromConnectionString(connectionString);
之前我從未考慮過實現這些靜態工廠方法，我並自嘲問不瞭解其內容。自從那以後，我改變了注意，讓我們深入探討其優缺點。
靜態工廠方法的優點
無須返回一個新的實例
而構造函數總是返回一個新的對象。
當新對象創建失敗時，你不能使用一個緩存的對象或返回 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));
這段代碼沒有功能上的差異，只是代碼風格上的一個問題。因此可能不應在決策中過分重視。
你能通過名字瞭解
對於某些對象，尤其是可以通過多種類似方式構造的對象-能夠在構造對象的方式上獲益良多。讓我們以Color類爲例，該類可以通過CMYK和RGB參數構造。
// 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);
與更具描述性的靜態工程方法進行對比，除非你知道Color的四個值的構造函數是CMYK，三個值的構造函數是RGB，否則無法通過閱讀代碼來區別出來。
我認爲，如果你有不同的構造對象的方式，尤其是參數彼此相似的方式，有很充分的理由來使用靜態工廠方法。
工廠方法可以返回不同的類
new Foo()總是返回一個Foo類的一個新的實例，Foo.FromBar很容易的返回一個IFoo接口，或者Foo的一個子類。一個可能與之相關的真實示例：
// 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（例如在庫上下文中）時，能夠根據輸入返回不同的實際類型可能非常有價值。特別是因爲這意味着你可以在接口或者基類後面隱藏一些實現細節。
我不確定應用程序代碼中的價值是否一樣大，你可以在其中控制整個庫代碼，並使大規模重構變得更加容易。
在構造函數中你不應該做的事情
通常，人們並不期望構造函數除了構造對象之外，還能做其他很多事情。你管你可以在構造函數中執行I/O，數據庫訪問等操作，但大多數人並不期望這樣做。按照慣例，你可以自由的以靜態工廠方法執行更多的工作，而無需任何人引起注意。
有些人也不認爲你應該在構造函數中拋出異常。也許這取決於語言，但在C#中完全可以，如果要在構造函數中創建非託管資源，請注意一下幾點。
靜態工廠方法的缺點
在構造函數中不應該做的事情
按照慣例，構造函數通常更簡單。當我調用構造函數時，通常不希望它執行I/O或
其他。這使構造函數的構造靈活性大大降低，這既是福也是禍。
意味着更多代碼
無論如何，你仍然需要構造函數來實際構造對象。靜態工廠方法是更多的代碼，而代碼是一中責任。它通常不是很複製的代碼，並且通常靜態工廠方法也不是特別長，因此這可能不是一個很大的缺點。
很難找到
通常，當我嘗試構造一個新對象時，我會先尋找構造函數。通過自動完成功能很難找到靜態方法，因爲他們通常無法與其他靜態方法區分開。
我認爲靜態方法最大的問題是你失去了可發現性。
經過研究和思考之後，我認爲我目前的看法是：
- 你應該始終創建一個構造函數，該構造函數將1：1映射到類內部的字段
- 如果你需要花很多實踐來創建對象（例如IO），或者對緩存對象並重新使用它們感興趣，請使用靜態工廠方法。
- 如果你需要API穩定(例如用於庫開發),請隱藏該構造函數並使用靜態工廠方法,因爲它爲你提供了實現的靈活性。
- 如果你有多種不同的方法來創建類,請創建靜態工廠方法並使用它們,因爲它們爲你提供了描寫性。