Helper classes

[Richard Bair]

>> But in the two examples provided by you, there are a too many factory
>> methods, maybe they do belong to a separate class. Just from the
>> javadoc point of view, it doesn't feel right to say "this is an
>> interface of something; and by the way, a dozen of factory methods are
>> defined here too"
> 
> OTOH, a traditional factory method is basically a "smart constructor",
> and it is reasonable to document factory methods in the same place we
> document constructors - i.e. with the class or interface being constructed.

To me the question is, where is it going to be more natural for a developer to find what they are looking for? The problem I've always had with utility classes is that you don't naturally find those (until you've been adequately exposed to the concept that, when looking for a method you cannot find, you decide to check to see if there is a utility class). That's one benefit to putting such methods on the interface or class. As a developer I've already got the interface handy, my code complete window is up -- and it gives me all of these additional very interesting things I can do.

I would err on the side of putting such methods on the interface (since err we must, as we're trailblazing here), and I suspect doing so we will be right more often than wrong.

Richard