在提供公共API（例如在库上下文中）时，能够根据输入返回不同的实际类型可能非常有价值。特别是因为这意味着你可以在接口或者基类后面隐藏一些实现细节。
我不确定应用程序代码中的价值是否一样大，你可以在其中控制整个库代码，并使大规模重构变得更加容易。
在构造函数中你不应该做的事情
通常，人们并不期望构造函数除了构造对象之外，还能做其他很多事情。你管你可以在构造函数中执行I/O，数据库访问等操作，但大多数人并不期望这样做。按照惯例，你可以自由的以静态工厂方法执行更多的工作，而无需任何人引起注意。
有些人也不认为你应该在构造函数中抛出异常。也许这取决于语言，但在C#中完全可以，如果要在构造函数中创建非托管资源，请注意一下几点。
静态工厂方法的缺点
在构造函数中不应该做的事情
按照惯例，构造函数通常更简单。当我调用构造函数时，通常不希望它执行I/O或
其他。这使构造函数的构造灵活性大大降低，这既是福也是祸。
意味着更多代码
无论如何，你仍然需要构造函数来实际构造对象。静态工厂方法是更多的代码，而代码是一中责任。它通常不是很复制的代码，并且通常静态工厂方法也不是特别长，因此这可能不是一个很大的缺点。
很难找到
通常，当我尝试构造一个新对象时，我会先寻找构造函数。通过自动完成功能很难找到静态方法，因为他们通常无法与其他静态方法区分开。
我认为静态方法最大的问题是你失去了可发现性。
经过研究和思考之后，我认为我目前的看法是：
你应该始终创建一个构造函数，该构造函数将1：1映射到类内部的字段 如果你需要花很多实践来创建对象（例如IO），或者对缓存对象并重新使用它们感兴趣，请使用静态工厂方法。 如果你需要API稳定(例如用于库开发),请隐藏该构造函数并使用静态工厂方法,因为它为你提供了实现的灵活性. 如果你有多种不同的方法来创建类,请创建静态工厂方法并使用它们,因为它们为你提供了描写性.以上就是C#的静态工厂方法与构造函数相比有哪些优缺点的详细内容，更多关于C# 静态工厂方法与构造函数的资料请关注易采站长站其它相关文章！
