[jdom-interest] converting Elements to objects
gillius at gillius.org
Fri Feb 18 13:50:41 PST 2005
Phil Weighill-Smith wrote:
> I must say, any academic who insists on the wheel being re-invented is totally off-beam; they should have you concentrate on the aspects of the project that are unique rather than the mechanical software development issues like XML <-> POJO transformations where there are plenty of existing and good solutions (most of which tend to be based on reflection, fyi).
In defense of his university, I mostly agree with that. Code reuse is very
important in industry and should be used, but professors who are trying to
grade projects can't be bothered to deal with whatever x number of random
libraries that students use that need to be installed and understood at some
level in order to grade the code.
Now for a thesis or some other major project, definitely libraries should be
used due to the size and scope of the project, and the uniqueness of your
solution -- also in these cases professors aren't going over code
line-by-line; they are more interested in input, output, and process used in
the project and are looking more at your writeup and test results.
Separate topic: A lot of people have been talking about reflection to do
this. While I agree that is certainly a nifty and elegant approach, I would
stay away from it not only because of slow run-time performance (if that is
important), but mostly because it requires an object form that is not
Personally I think having gets/sets blindly for all variables is bad and
defeats the point of encapsulation. Also for some classes you want them to
be read-only classes (similar to String or others), and you don't want to
provide set methods. Sometimes you don't want to expose the structure of
the object (which you do if you blindly create get* and set* for all
variables), and you might want to have a point class that is free to use
cylindrical, spherical, or cartesian coordinates internally as long as it
supports the logical operations you'd want to do with it. If you can't
modify the class you are trying to load, because it came from someone else,
then you may not be able to guarantee properly-named methods. Lastly, I
think it is unwise to tie the XML schema and object definition together so
directly -- you want to shield yourself from changes in tag names etc, so if
you want to rename a variable from "PhoneNumber" to "HomeNumber" you don't
also have to change all XML documents in existance.
And since reflection is done at runtime, you can't tell your errors until
then -- this isn't like an Interface where you are forced by the compiler to
conform to a set of methods. So there is a lot more error checking and
handling required and that complicates code more than it needs to be.
That said, I don't think reflection-based loading is a _bad_ idea -- just
probably not the best. I certainly enjoy greatly the benefit that a library
like JUnit gives me through reflection and a loosely-defined interface.
More information about the jdom-interest