[jdom-interest] Re: carrying user data around with Element

[Patrick Dowler]

On Thu, 16 Nov 2000, you wrote:
> > > It would basically add the following to the Element class:
> > > 
> > > public void setUserObject( Object o);
> > > public Object getUserObject();
> > 
> > <nit comment="java beans are only good for tool developers">
> > What makes this any better, in practice, than
> > 
> >         public Object user_data;
> > </nit>
> 
> I think its called encapsulation ;)

This is not really encapsulation. The user of the class knows 
everything about the inner workings of java bean-like classes. They
are essentially structs with two methods in addition to the member
variable.

It is only encapsulation if the inner workings are being hidden. By
definition, user_data is never hidden so there is no encapsulation.
That is my beef, in a nutshell - an IMHO if there ever was one :-)

>

I wasn't meaning to flame - sorry if it came off that way :-) 
 
> <flame-retardent>
> For all of the many possible uses of user data, its a pretty good "bang
> for the buck" feature creep.  It doesn't even require testing, exactly. 
> Why is something to flame about?  My question was as to whether there
> are substantive objections to adding this?
> </flame-retardent>

It is quick and easy, to be sure. It is also not type safe, so you have to
"know" what is there and cast, or use a bunch of instanceof and cast...

I understand that the thinking so far is that a subclass with user data 
(which isn't really in any danger of breaking when the base class changes,
BTW) is the better route because you get type-safety for your app and
you can do the software engineering thing and ensure some sort of 
state-invariant. A generic user object doesn't let you have either, so 
anything beyond a trivial project wouldn't likey use it anwyay.

cheers,

-- 

Patrick Dowler
Canadian Astronomy Data Centre