Details
-
Improvement
-
Status: Open
-
Resolution: Unresolved
-
1.8
-
None
-
None
-
Operating System: other
Platform: Other
Description
I'd like the batik bridge package to function more like a Builder or Abstract
Factory pattern from the Design Patterns book so that 3rd parties could take
advantage of the existing reader code in bridge to build their own graphics node
implementations. (Note that the book also contains a "Bridge" pattern, but I
don't think batik.bridge is that kind of bridge. It seems more like an Abstract
Factory) The builder/factory would build a tree of graphics nodes of which gvt
would be one implementation. To accomplish this I'm trying to create an abstract
factory layer between gvt and bridge so new clients can create their own object
trees by subclassing the abstract factory classes.
I'm not a batik expert, so I'm looking for feedback on whether this project
seems doable and/or desireable, and if so, on implementation issues. I've done a
skeletal first pass of creating the abstraction. In the attached code I've
created a new package, org.apache.batik.bridge.gnode, which includes a set of
interfaces that encapsulate the gvt-specific method calls made from the bridge
classes. I've refactored some of the bridge classes so they only reference the
new gnode interfaces, and I've moved some gvt-dependent bridge classes to a new
package, org.apache.batik.bridge.gvt. (that may not be the best place for them,
but that's where they are now). Those classes are dependent on gvt.
I've also created 'demo.batik.bridge.myvt' which contains factory classes to
build trees of objects from package 'demo.myvt'. I've only refactored a small
bit of the existing classes. I'm posting this here to see if I can get feedback
on what I've done so far. Thanks for your comments.