Re: Observable collections (set, list, map)
On 9 Aug., 13:14, Thomas Hawtin <use...@tackline.plus.com> wrote:
Karsten Wutzke wrote:
Does anyone know of a collection package/API that extends
java.util.Observable collection classes such as Set, List and Map?
I don't know why you would want to use Observable. The event/listener
idiom is the standard way to go about these sorts of things.
Although I haven't used it myself, Glazed Lists seems to have attracted
positive comments.
http://publicobject.com/glazedlists/
Tom Hawtin
Well I have written some code that attaches any custom Observer
interface to any java.util.Observable. The code will generate adapter
classes *on the fly* that will downcast from Observable to the custom
observer interface:
public class SelectionObserverAdapter implements java.util.Observer
{
private SelectionObserver so;
public SelectionObserverAdapter(SelectionObserver s)
{
if ( s==null )
{
throw new NullPointerException("Selection observer is null.");
}
so = s;
}
public void update(Observable obs, Object arg)
{
so.update((Selection)obs);
}
}
Any Observable will have some custom adapter attached to be notified
on update. I wanted to avoid the downcast for every Observer
implementation and use custom observers like
public interface SelectionObserver extends GenericObserver
{
public void update(Selection s);
}
public interface EmailConstraintsObserver extends GenericObserver
{
public void update(EmailConstraints ec);
}
....
The observing class then only has to implement the respective custom
interfaces. Note attaching the two is done via generating byte code,
if I would'nt do this, I'd not only have to create the concrete
Observer interface but also an adapter class, which is a maintenance
nightmare. Since it works so nicely without this listener stuff I was
looking for Observable compatible collections...
Side notes:
1. The adapter mainly acts as a "method multiplexer", it calls the
right method due to the downcast in the update method.
2. I know the object of interest in observer is Object arg, I wanted
to get around downcasting as much as possible.
3. The code will add n adapters for every n custom observers
implemented in the observing class, so Observable will do n updates.
As this is only intended for a few connections, the overhead of
calling notifyObserver n times is not (yet?) recognizable. This is
still much cleaner than using some if then else construct with
downcasts to determine the concrete object's class.
4. Of course, I used some naming conventions for the whole class
generation stuff...
Well..... this explanation has gotton much bigger than intended. I
hope that the basic idea has become clear. In any case this is getting
a little off-topic now - I just wanted to outline my motivation.
I'm not really a friend of Java's listener concept, can't explain why
really... ?-/
Karsten