Default methods syntax/semantics [Re: Updated State of the Lambda]

[Alessio Stalla]

On Tue, Dec 13, 2011 at 2:29 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
>>> Eventually it seems likely that many cases where people would use
>>> abstract classes today (those that are stateless) will morph into using
>>> interfaces as a weak form of stateless traits.
>>
>> I'm hoping we can deprecate the pattern where you have an interface Foo
>> plus an abstract class AbstractFoo that provides an implementation skeleton.
>> It seems much more elegant to have an interface Foo that also provides
>> the implementation skeleton, which should be possible with default methods,
>> at least in many cases.
>
> Yes, but only if there is no state in the AbstractFoo.

I often find myself writing multiple "obvious" overloads for the same
method which only provide default values, or massage their arguments a
little bit... those end up in AbstractFoo and are inevitably
copy-pasted when extending AbstractFoo is not an option for whatever
reason. That's one valid reason to prefer interfaces with default
implementations to abstract classes - in those cases at least.

--
Alessio