[jdom-interest] Re: carrying user data around with Element
Patrick.Dowler at nrc.ca
Thu Nov 16 09:30:26 PST 2000
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
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 :-)
> 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?
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.
Canadian Astronomy Data Centre
More information about the jdom-interest