Take the 2-minute tour ×

I'm trying to think of the cleanest way to implement a couple of methods that open a file.

Consider the following method signatures:

public static DomainObject Load(Uri urlToFile)
    /* downloads file and calls Load(savedToFilename) */

public static DomainObject Load(string filename) 
    /* creates filestream and calls Load(stream) */

public static DomainObject Load(Stream stream) 
    /* does actual loading */ 

I'm trying to implement some concepts from Clean Code, specifically:

When constructors are overloaded, use static factory methods with names that describe the arguments. For example,

Complex fulcrumPoint = Complex.FromRealNumber(23.0);

is generally better than

Complex fulcrumPoint = new Complex(23.0);

Now, I know I do not have overloaded constructors, per se (I refactored away from that), but I think the principle is the same. So that implies that my Load methods be refactored to something like:

public static DomainObject FromURI(Uri urlToFile);
public static DomainObject FromFile(string filename);
public static DomainObject FromStream(Stream stream);

But, tbh, I think it's more intuitive to use what I've already got. From a consumer's perspective it feels like Open will take whatever source I happen to have whereas the other method requires me to think first about what my source is and then wonder if there is a specific method for that.

So I ask, from your more experienced viewpoint, which is better and why?

share|improve this question
I would consider Clean Codes method bloat. I can see that 23 is a real number; why do I need the method name to say that? –  alternative Oct 11 '10 at 0:25
I agree with mathepic that it does seem like code bloat. I would say it may be valid if you work in a language which doesn't have a de facto IDE (i.e. PHP vs. C# & Visual Studio), or if the IDE doesn't support intellisense. However, if intellisense is supported or offered, then I'm typically OK with overloaded factory methods, since they can indicate what the type of the expected parameter(s) and their names should be representative of their use. –  Hugo Oct 11 '10 at 2:41
add comment

1 Answer

up vote 8 down vote accepted

I think "Load" is the way to go for a few reasons:

  • The parameter type is already in the parameter list- why specify it again in the method name?
  • If you happen to have multiple methods that produce something a stream in a class, "FromStream" becomes a problem.
  • In the age of intellisense, it's much more logical to type "Load" and get a list of possible parameter options, rather than look at three different methods (especially if more methods than just those in this set happen to start with "From").
  • Another decent rule of thumb is "name methods after verbs when you can," which votes in favor of something akin to "Load," or at least "LoadFrom..."
share|improve this answer
Totally! And not to mention, it's so much cooler to say "method overloads". –  aredkid Oct 11 '10 at 6:07
+1 for good answer. Also, all methods exhibit the same behaviour and return the same result; as such, it's better to overload the method as it makes this point clear to the programmer (you, in this case). If you use slightly different names, the programmer might get confused. Finally, "FromXYZ" doesn't tell you what the method does, but "Load" does (well, maybe it could be named even better, but it's vastly better than "FromXYZ" at least). Always strive for self-commenting code. –  gablin Oct 11 '10 at 6:50
add comment

Your Answer


