RE: RE: [platform-swt-dev] org.eclipse.swt.SWT

["Jeff Brown" <j9brown@xxxxxxxxxxxxxxxxx>]

I swore I wouldn't get involved, but I spent some time analysing the
applicability of the Bridge pattern to SWT about a year and a half ago.

First off, much of the Bridge pattern's strength comes from the ability to
dynamically select and instantiate the internal implementation class at
runtime.  Bridge also makes it easier to hide implementation details that
crosscut a class hierarchy at multiple points.  For some languages, Bridge
also addresses some binary compatibility concerns.  Alternate solutions to
these problems include dynamic inheritance, message dispatch filters,
modules, and aspects.

Bridge's main cost of course is that a parallel hierarchy must be
constructed and maintained.  Some additional ugliness results from
difficulties in managing the lifecycle of the linked objects.  You can think
of the interface object and its backend implementation object as forming a
handle-body pair except that state may be distributed or mirrored across the
two objects.  Garbage collection alleviates some of this concern.

One can directly analyse the effects of applying the Bridge pattern to
windowing toolkits by comparing AWT with SWT.  A few observations:

0) For lifecycle issues, AWT introduced an ugly hack called "addnotify()".
This is compounded by the brain-dead way in which AWT's containers work.
Now all widgets have to worry about an extra "not yet realized state".  Note
that the Bridge pattern does not require this sort of thing.

0) State information about each widget must be duplicated between the
implementation and interface classes in case the implementation class goes
away.  Again, not strictly Bridge pattern's fault.  More due to a design
decision gone wrong.

1) Bridge pattern requires a parallel class hierarchy.  This is evil.  In OO
languages that lack native method delegation facilities, this results in a
lot of messiness to do with duplicating interfaces everywhere.  We're
talking huge gobs of boilerplate code to maintain.  Ugh.

2) SWT does not require dynamic selection and instantiation of
implementation objects.  Goodness!  Most of the classes for other window
toolkits won't LOAD without throwing runtime exceptions due to missing
native libraries!  Over the course of a program's lifetime, it will only
ever interact with ONE window system.  Period.

3) With extra code for delegation come increased demands on resources.  More
classes => bigger class files => longer load times => poorer execution
times.  One might hope that a clever JVM would inline out delegation.  This
is only possible if the delegate object is stored in a "final" field.  Of
course, AWT doesn't do this...

4) Don't get me started on the foolishness of trying to subclass interface
classes in the Bridge pattern.  Want a template method?  Can't have one!
You'd need to let the implementation classes know about the interface
classes.  But you can't have that...  So all you need is an Observer right?
Or you can move some of the sequencing logic up to the interface class
level.  This sort of reasoning quickly balloons out of proportion.

5) So, what we're really buying with Bridge in this case is a very expensive
wrapper to handle some annoying visibility and (possibly) binary
compatibility issues.  These issues would go away if Java provided something
more like the ML module system for extracting multiple views (ML structures)
of an interface.

I honestly think that this thread has gone on much too long.  There's simply
no sense arguing philosophy until the time comes to develop SWT-NG in 4-5
years (just speculating).  And then you know what?  It'll probably be
implemented using whatever new fancy tools are in vogue like Aspect Oriented
Programming.  Many "mistakes" again will be made.  Different ones.

It's odd how some people immediately jump upon a toolkit for discouraging
subclassing as a means of customizing, changing, or adding behaviour.
Aggregation and composition are also nice...  Particularly given the right
mix of helpful language facilities.  Keep in mind that the same amount of
thought must go into constructing a class library that is "open" to
subclassing as must go into constructing a class library that is "open" to
customization via composition.  There's very little difference semantically
between a "template method" and an "observer" or "strategy object" when you
get right down to it.

There are certainly lots of things to gripe about with the SWT API.  Let's
talk about those instead, IN CONCRETE TERMS.  Disagreements about philosophy
is why there is no "one true" I/O library, or "one true" linear algebra
toolkit, or "one true" Operating System, even "one true" programming model.
However, each incarnation has equal opportunity of working well on a
particular part of the problem space.  Don't like one tool, adapt it, use
another, or construct a new one.  Diversity rocks!

Pragmatically yours,
Jeff.