Hello Lars,
John Reimer wrote:
Since I'm not a Java developer (or, to be honest, any kind of
developer
beyond a language enthusiast), I'd say I'm not in a good position to
question the design decision of Java source that uses cyclic
dependencies
(such as SWT).
All I can say is that I can agree that it looks like a bad idea
because
I can certainly see the painful problems it can produce.
I haven't used SWT enough, and certainly not looked much at the
internals, to say whether I consider this a problem there or not.
However, I've been using GWT for a while, and there was this widget I
wanted to use. Unfortunately for me it missed a feature (or the
ability to turn off a feature really) that I needed. And since it
wasn't possible to fix this by subclassing either, I had to
reimplement it all. Now, this wouldn't be so bad, but as it turned out
it depended on a few other classes, and 4 or 5 of those had a back
dependency on the main widget, meaning I had to reimplement those too.
As it was, the discerning functionality of the main widget could have
(should have) been put into an interface, the helper classes depend on
that interface instead, the feature exposed, and by that time it would
already be of much higher quality. Some more work would probably be
needed with regards to the helper classes, but in the original code
all of them could as well have been private classes of the widget.
It is definately much more difficult to properly design code such that
it has fewer cyclic dependencies, but I think that the choice between
bottom-up or top-down approach will affect this a lot. If you start at
the bottom, you're probably more likely to get a good result in this
respect, just because there is only lower-level functionality to pick
from when building the higher-level components. I do of course
understand that bottom-up may not be the most obvious choice if
high-level functionality is what you need in the first place.
Thanks for the explanation. I forgot about interfaces, which is probably
a pretty big "OOP's" on my part ;-D. I imagine it to be a good way to solve
this particular import interdependency problem in D, although, depending
on the project, the approach may prove insufficient.
Alas, this is the unforunate thing about porting large software projects
and that one continues to urk me: you rarely can afford to change the design
in such away that it adopts the most sane approach for a given situation
(or the given language you've ported it to). So it seems that the ideal
of good design is sometimes stymied by project requirements and apparent
language compromises for platform technologies.
My problem with most projects I work on is the (nearly) insatiable desire
to have it done right or at least to look "right". However, it is strangely
apparent that "right" isn't always clear, but "wrong", done thoroughly, is
horrifyingly obvious. Porting software has been hard because I've dearly
wanted to fixup all things that I perceive to be messy, even at the expense
of "if it ain't broke, don't fix it". This mentality, naturally, compromises
productivity. However, practicality inevitably overrides many decisions
to indulge the ideal of productivity. :)
The good news is that, after seeing the problems incurred by design decisions,
I feel more motivated to understand the meaning of the concept of "good design".
-JJR
