Helper classes

[Brian Goetz]

I think we're at risk of overrotating towards the new shiny toy.

Some static methods are essential and/or high-value; some are 
inessential and/or low-value.  Putting the former in the interface 
increases the value of the interface; putting the latter in the 
interface decreases it.

An example of a method that should have been in the interface from day 
one is DriverManager.getConnection() -- it's basically the only way to 
get a JDBC connection.  Clearly it belongs with Connection; you can't 
even figure out how to get a Connection (and you're not going to 
implement one yourself) by just looking at the Connection Javadoc.

An example of a method at the other end of the spectrum is 
Collections.rotate(List, int).  Sure, this is useful when you need it, 
but it just isn't that important, and weighing down an interface with 
5000 lines of additional code (OK, Collections is only 4700 LoC) really 
clogs up the Collection interface.

Sadly, judgement is needed.

On 4/15/2013 5:23 PM, Sam Pullara wrote:
> I don't feel like we would be having this discussion if Java always
> had statics in interfaces. It is the obvious place to put helpers that
> are factories and other cases that do not act directly on the
> interface type. So much so that people often put an inner class in the
> interface just to get some semblance of this behavior.
>
> Sam
>
> On Apr 15, 2013, at 1:59 PM, Luc Duponcheel <luc.duponcheel at gmail.com> wrote:
>
>> Hello,
>>
>> Here is my opinion on this:
>>
>> Functionality naturally belongs to interface, say Zyx, if one of it's
>> parameters is of type Zyx
>> (and if an argument passed to it is, naturally, eagerly evaluated).
>>
>> Other functionality naturally belongs to helper class. say Zyxs (or
>> ZyxStatics for that matter).
>>
>> for example:
>>
>> - transforming an element to a singleton list containing it naturally
>> belongs to the helper class
>> - joining a list of lists naturally belongs to the helper class
>>
>> On the other hand it is sometimes useful to have static versions of methods
>> in Zyx in Zyxs because they can naturally be used as method references.
>>
>> About discoverability:
>>
>> When, for example, working with lists, I hope that there will be zipper
>> functionaity transforming a tuple of lists into a list of tuples. That
>> functionality naturally fits in the interface Zyx (maybe with a copy in the
>> class Zyxs). I also hope that there will be unzipper functionality
>> transforming a list of tuples into a tuple of lists. That functionality
>> naturally fits in the class Zyxs. So, if you know what method you are
>> looking for (also in terms of its signature) you often know where to look
>> it for.
>>
>> By the way:
>> my experimental JavaZ library (https://github.com/JavaZ) contains many
>> examples:
>>
>> e.g. bindF (a.k.a. map) in Zyx has a version liftF in ZyxStatics (its
>> method reference is used in foreach)
>>
>> Luc
>>
>> --
>>    __~O
>>   -\ <,
>> (*)/ (*)
>>
>> reality goes far beyond imagination
>>
>