Oh, by the way,
On 30. 3. 2016, at 17:12, Jochen Theodorou <blackdrag@gmx.org> 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
|