Are you sure this is a valid answerable question? This is a wrong approach to understanding things.
You don't need to look for benefits. Instead, you need to 1) understand what exactly one or another language and platform feature does; 2) analyze what do you need to achieve; 3) based on that previous item, choose the expressive feature of language which suits you more.
Don't even try to think in terms of "benefits". Your final decision should provide benefits. Language features do not have benefits, they all are needed (in a good language, of course). It all depends on purpose.
Comparison on the two kinds of method simply makes no sense. But you can compare two or more use cases. Let's consider them.
class MyClass {
internal static MyClass Create(string initializationParameter) {
return new MyClass(string)
}
private MyClass(string initializationParameter) { }
}
class MyClass {
internal MyClass(string initializationParameter) { }
}
Here, you can instantiate
MyClass
in different ways, and it's quite apparent that first way is excessive and pointless. But there are cases where first approach (which we can call
factory method makes a lot of sense).
Consider one use case from the .NET FCL, the class
System.Net.WebRequest
:
http://msdn.microsoft.com/en-us/library/system.net.webrequest%28v=vs.110%29.aspx[
^].
Let's understand why you create instances of this class not via its constructors, but via its factory methods
Create
? These two:
http://msdn.microsoft.com/en-us/library/system.net.webrequest.create%28v=vs.110%29.aspx[
^].
This class is
abstract. So, not having its instance, you can call only the static members, including the factory methods. These methods will return you the instance of this class, but
runtime types of this instance cannot be of the abstract class. These runtime types of the instances will be some derived, non-abstract type. The actual type to instantiate depends on the initialization parameter representing URL. Depending on the URL scheme ("http://", "htts://", "ftp://"), the factory methods chose appropriate derived implementation class. This mechanism leverage "true" OOP, late binding based on virtual methods.
—SA