Helper classes

[Sam Pullara]

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
>