[jdom-interest] converting Elements to objects

[Jason Winnebeck]

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 
strongly defined.

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.

Jason