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 privat! e 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. -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
