Helper classes

[Stephen Colebourne]

On 15 April 2013 18:28, Brian Goetz <brian.goetz at oracle.com> wrote:
> 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.)

JSR-310 will adapt to any guidelines that are created. But I think as
Richard explained, it does tend to be a lot easier to find the
implementations if they are in the interface.

For example, someone scanning the documentation, either Javadoc or
code completion, may not know what the with(TemporalAdjuster) method
does. If cicking through to the interface TemporalAdjuster provides
some implementations, then its a good way to start learning.

More generally, I see static methods on interfaces as a way to reduce
the negativity of Java (EE) designs were there are factories on top of
factories. With the new feature, the factory can be on the interface,
reducing the Javadoc size and the conceptual surface area.

Just to note that 310 has 2 types of method on TemporalAdjuster. One
is creational/adapting - ofDateAdjuster(), and the rest are simple
implementations for general use (and intended for static import).

Stephen