Helper classes

[Zhong Yu]

I was talking about an interface with only default instance methods.
The interface can be subtyped and the methods can be overridden. This
opens some interesting design possibilities. I have a private use case
that this pattern is perfect for.

Zhong Yu

On Mon, Apr 15, 2013 at 5:07 PM, Paul Benedict <pbenedict at apache.org> wrote:
> Zhong, but at least you can prevent instantiating a class with "final" or
> throwing AssertionError in a private constructor. If you create an interface
> with all static methods, you will still have an interface that someone can
> extend or implement.
>
> Paul
>
>
> On Mon, Apr 15, 2013 at 5:01 PM, Zhong Yu <zhong.j.yu at gmail.com> wrote:
>>
>> Also there's another design possibility: a vacuous interface,
>> containing no abstract methods, but all default methods, for example
>>
>>     public interface Math
>>         int max(int, int)
>>
>> as contrast to the traditional way: a vacuous class, not a template
>> for objects, but only as a namespace hosting static methods.
>>
>> Zhong Yu
>>
>>
>> On Mon, Apr 15, 2013 at 4:23 PM, Sam Pullara <spullara at gmail.com> 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
>> >>
>> >
>>
>