Helper classes (original) (raw)

Zhong Yu zhong.j.yu at gmail.com
Mon Apr 15 15:24:41 PDT 2013

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 >> >

More information about the lambda-dev mailing list