[jdom-interest] Element Reference from Attribute
Patrick.Dowler at nrc.ca
Mon Nov 27 12:18:17 PST 2000
On Mon, 27 Nov 2000, you wrote:
> I was reading Bertrand Meyer's Object Oriented Software Construction
> over the holiday (definitely heavy thinking) and that gave me a new
> perspective on part of the debate in this thread. Meyer talks about
> the notion of trading storage for computation in features (method
> calls, to Java programmers) and I think maybe that's what we need
> here for the getParent() method. In brief:
> 1. All nodes classes (Element, Attribute, ProcessingInstruction,
> etc.) have a getParent() method that behaves correctly; i.e. it
> returns a reference to the parent unless there is no parent in which
> case it returns null. This method never throws an
> UnsupportedOperationException or anything similar.
> 2. In some classes this method will be implemented via storage; that
> is, each object will hold a reference to its parent which is simply
> 3. In other classes, this method is implemented via computation; i.e.
> walk the whole document tree to find the parent but don't store it.
> Individual programmers could use the builder/factories to decide
> which version they wanted. However, the key idea is that in all cases
> the API and behavior is the same. Each programmer gets to decide
> whether they care more about storage or computation. This might
> however be an issue for 1.1. For 1.0 I recommend using the simpler
> solution, storage. We can add the computational option in 1.1.
This definitely does not cover the whole argument. One of the side-effects
of parentage (especially for storage) is that you cannot add the same
attriibute to multiple elements, this ruling out any object sharing that the
developer knows to be safe or at least desirable. Computation does not make
this plausible, IMO.
Splitting Element into BaseElement and Element, along the lines that
BaseElement can be read and written (ie. supports the basic XML stuff),
has no ill effect on Element. It does allow others to implement alternate
Element classes (as you suggest: trading storage for computation is a
good example of it, there are many).
Element should be the standard/default/primary class. It should support
the nice things people need as afar as navigation goes. BaseElement
should do the stuff about which there is little or no debate - IO of XML data -
and that everyone needs, regardless of application.
Think of BaseElement as an abstract base class but not actually declared
abstract so that people can use it if they wish, especially for more highly
constrained systems (performance, size, etc.).
There is little to lose and everything to gain.
Canadian Astronomy Data Centre
More information about the jdom-interest