[jdom-interest] Announce: JDOMPlus a flexible XML framework f or Java

[James Strachan]

----- Original Message -----
From: "Jason Hunter" <jhunter at collab.net>

> > Java 2 Collections implement read only collections via alternate
> > implementations of the collections interfaces. There are singleton
> > immutable collections:-
> >
> >     Collections.EMPTY_LIST;
> >     Collections.EMPTY_MAP;
> >     Collections.EMPTY_SET;
> >
> > Each of these use private implementations of List, Map and Set
> > which fully implement their respective interfaces, they just throw
> > UnsupportedOperationException when someone attempts to change their
> > value.
>
> Those aren't the classes that implement the unmodifiable behavior.  You
> should look at UnmodifiableList in Collections.java.

You cannot modify EMPTY_LIST, EMPTY_SET or EMPTY_MAP so they do implement
unmodifiable behavior.

I was slightly splitting hairs but was trying to explain that your original
point of...

http://lists.denveronline.net/lists/jdom-interest/2000-December/003983.html

> I think read-only trees have their place.  However, I
> lean toward having them implemented the same way Collections do, with
> facade classes.

... was incorrect.
All I'm saying is that I don't think the "Facade" design pattern is used to
implement read only collections.
My brief reply is that I think its the "Proxy" pattern instead.

Taking UnmodifiableList as an example, this is used to create unmodifiable
list instances via the Collections.unmodifiableList() method.
The UnmodifiableListis an example of the "Proxy" pattern, not "Facade".
UnmodifiableList is-a List. It doens't introduce a new interface, like a
"facade" does, it just implements an existing interface "List".

According to this site:
http://rampages.onramp.net/~huston/dp/patterns.html

the "Proxy" design pattern is described as

"Provide a surrogate or placeholder for another object to control access to
it. "
"Adapter provides a different interface to its subject. Proxy provides the
same interface. Decorator provides an enhanced interface. [GOF. p216]"
"Decorator and Proxy have different purposes but similar structures. Both
describe how to provide a level of indirection to another object, and the
implementations keep a reference to the object to which they forward
requests. [GOF, p220]"

Looking at the source of UnmodifiedList we see that it uses an internal
"surrogate" reference to the real list while disallowing certain
(non-read-only) methods to be performed. The Proxy pattern is particularly
useful for doing other things too, like lazily constructed collections which
can be useful for lazily evaluating database calls, XInclude, XLink/XPointer
and such like.

One interesting point is if we implement a proxy in JDOM we get a memory
inefficient implementation. A Proxy usually only requires a single surrogate
object. e.g.

public class UmmodifiableElement extends Element {
    private Element proxy;

    public UmmodifiableElement(Element proxy) {
        this.proxy = proxy;
    }

    public String getName() {
        return proxy.getName();
    }

    public void addContent(Atttribute attribute) {
        throw new
upportedOperationException( 
            "This element is read only, you cannot change it" 
        );
    }
}


So using the proxy pattern we can implement a read only element in JDOM.
However because we can only derive from Element (there is no lightweight
base class or abstract base class of any kind or interface we can implement)
we inherit all of Element's instance data. This is currently 7 instance
variables which we do not need or want. That is 7 instance variables too
many IMHO and why I'm (unsuccessfully it appears) arguing for some kind of
interface or abstract base classes in JDOM, for efficiency & flexibility
reasons.


<James/>


James Strachan
=============
email: james at metastuff.com
web: http://www.metastuff.com




If you are not the addressee of this confidential e-mail and any
attachments, please delete it and inform the sender; unauthorised
redistribution or publication is prohibited. Views expressed are those of
the author and do not necessarily represent those of Citria Limited.