In Java 8+, interfaces can have static methods, and with default methods, you
can simulate multiple inheritance. To be honest, I'm not sure how/if you can
use this from Groovy -- if Groovy interface can define static or default
methods. In the case of conflicts, Java forces you to override the shared
method. From the override you can call one of the super class versions if you
want.
public interface Foo {
static String getFoo() {
return "Foo";
}
default String foo() {
return getFoo();
}
default String shared() {
return foo();
}
}
public interface Bar {
default String bar() {
return "Bar";
}
default String shared() {
return bar();
}
}
public class FooBar implements Foo, Bar {
public static void main(String[] args) {
FooBar fooBar = new FooBar();
System.out.println(fooBar.foo());
System.out.println(fooBar.bar());
System.out.println(fooBar.shared());
}
@Override
public String shared() {
return Foo.super.shared();
}
}
Jason
-----Original Message-----
From: OC [mailto:[email protected]]
Sent: Wednesday, March 30, 2016 12:59 PM
To: [email protected]
Subject: interface/implementation patten (was: Proxying how to?!?)
Oh, by the way,
On 30. 3. 2016, at 17:12, Jochen Theodorou <[email protected]> wrote:
> This again forces people to split their classes in interfaces and
> implementations
reminded me another question of mine. I actually want to embrace this pattern
for a long time (after all, I am used to it from ObjC), but there are two
problems:
(a) interfaces cannot contain static methods
I am afraid there would be no solution at all in Java-based world, or does
Groovy bring some?
(b) they force me to maintain two parallel hierarchies, like
===
interface Foo {
def foo();
...
}
class Foo_Implementation implements Foo {
def foo() { ... }
def myfoo() { ... }
...
}
interface Bar implements Foo {
def bar();
...
}
class Bar_Implementation extends Foo_Implementation implements Bar {
def bar() { ... }
...
}
===
with a high danger of a mistake leading to inconsistence of these two
hierarchies. Not speaking of the factory pattern to replace those pesky static
methods, which would, alas, add a third hierarchy for factories; if I wanted to
use interface/implementations for factories too, I get _four_ parallel
hierarchies, which need to keep consistent! Quadruple ick.
Is there some trick in Groovy which makes this task groovier (or at the very
least reasonably manageable), or am I up to my own source preprocessor and/or
ASTTs (which again would clash with traits :/ )?
Thanks a lot,
OC
----------------------------------------------------------------------
This email message and any attachments are for the sole use of the intended
recipient(s). Any unauthorized review, use, disclosure or distribution is
prohibited. If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message and any attachments.
