Public defender methods and static inner classes in interfaces?

Thomas Jung thomas.andreas.jung at googlemail.com
Tue Aug 24 01:08:21 PDT 2010


There has already been some discussion about the syntax of the
defender methods. Numerous responses were not in favour of the
delegation syntax.

Inline syntax and delegation syntax are mostly interchangeable except
that the delegation syntax can resolve the case better that multiple
default method definitions for the same method (from different
interfaces) actually delegate to the same static method (this is not
ambiguous).

And yes, inline static classes (that are public to the consumer of
library) won't keep the implementation code out of the interface and
in this regard the syntax is not perfect. It will be quite common for
new interfaces to have there default implementations as inner classes.
I'd say it is the best place to put them as long as they are only used
by this one interface. It would be nice if the visibility of the class
could be private (not sure this is backward compatible).

On 24 August 2010 04:09, David Walend <david at walend.net> wrote:
> Some style questions: Will it be good taste or bad to include static
> inner classes inside interfaces to provide the default implementation
> of public defender methods? For example
>
> public interface Outer {
>
>     public extension void method(Object parameter)
>        default Inner.method;
>
>     //more extension methods
> ...
>
>     public static final class Inner {
>
>         private Inner() {}
>
>         public static void method(Outer outer,Object parameter) {
>                //some code
>         }
>         //more implementations of extension methods
> ...
>     }
>
> }
>
> Does using a static inner class this way run counter to the goal of
> keeping code out of interfaces (mentioned at then end of section 2 in
> the defender method spec)?
>
> What (if anything) is broken if almost all of the methods declared in
> Outer are implemented by Inner?
>
> Thanks,
>
> Dave
>
>
>


More information about the lambda-dev mailing list