Helper classes
Brian Goetz
brian.goetz at oracle.com
Mon Apr 15 10:28:45 PDT 2013
Yes, I agree with this sentiment. It's clear that:
- Never put methods that would have gone in class Foos into interface
Foo from now on
and
- Always put the methods that would have gone in class Foos in
interface Foo from now on
are both equally naive guidelines. Which means that getting things
right will require a lot of careful thought, and that mistakes will be
made as we figure out the new rules.
To the specific point, I agree that these two 310 classes are a good
example of where we should still consider a class; an interface with one
abstract interface method and a dozen implementations (when there could
as easily be half a dozen or three dozen) seems distinctly fishy.
I think a key distinction is whether the implementations provided are
simply there for convenience (i.e., any competent user of the API could
have written them, but we provide them so you don't have to) or there
because they cannot be provided from outside (perhaps because they
require the use of otherwise private implementation detail.) Because in
the former situation, the interface is clearly *more important* than the
implementations (arguing for putting the implementations elsewhere),
whereas in the latter case, they are equally important as one cannot
live without the other (justifying why they should live in the same place.)
On 4/15/2013 1:13 PM, Zhong Yu wrote:
> On Mon, Apr 15, 2013 at 3:53 AM, Stephen Colebourne
> <scolebourne at joda.org> wrote:
>> Currently, Project Lambda has a number of helper clases, notably
>> Collectors and Streams, which are clearly related to the interface.
>> Since JDK8 has static methods on interfaces, are there plans to move
>> the static methods to the interface?
>>
>> This would allow methods such as intBuilder(), emptyIntStream() and
>> singletonIntStream(int t) to be on IntStream rather than on Stream,
>> and thus have the simpler names of builder(), emptyStream(),
>> singletonStream().
>>
>> Making the change might also affect some method names, as sometimes
>> they read differently, or are otherwise confusing, when on the
>> interface.
>>
>> As a note, on JSR-310, we did move the methods from similar static
>> helper classes to the interfaces:
>> http://hg.openjdk.java.net/jdk8/tl/jdk/file/f4d50e8cc9e2/src/share/classes/java/time/temporal/TemporalAdjuster.java
>> http://hg.openjdk.java.net/jdk8/tl/jdk/file/f4d50e8cc9e2/src/share/classes/java/time/temporal/TemporalQuery.java
>> although I'm not sure that counts as precedent yet.
>>
>
> Stephen, I feel it's ok to include one or two static factory methods
> in an interface - it was very annoying to have to create another class
> just to host one or two methods.
>
> 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"
>
> Zhong Yu
>
More information about the lambda-dev
mailing list