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
