(Okay, value object, transfer object, model object, whatever you want to call them: basically an object that represents a "thing").
The "standard" way of developing a POJO follows the JavaBean spec:
- Data memembers
- Mutators (getters and setters)
- Empty Constructor
Then you can override equals() and hashCode(), implement Comparable, and all sorts of other fun things. One of these is to override toString() from Object to spit out some sort of
String representation of the object. If it's not overriden, then toString() just spits out some default information about the Object.
Now, in the past, I've done things like create an interface called HashableEntity with a single method to export the data as a HashMap (trust me, it made sense at the time...), or other representations.
Now I find myself wanting to create an interface called something like SoapEntity, with a single method called toSoapMessage() (obviously returning an object of type SOAPMessage). Now, this is a bit more heavyweight than my previous examples, requiring the import of all sorts of stuff from the javax.xml.soap package.
The other option is a Utility class or Service class method to take the POJO and return a SOAPMessage.
(I suppose one other option would be a Decorator for the POJO, as well).
What would be the arguments for or against having the logic in the POJO (other than the overhead I mentioned previously)? I feel that putting the logic into the POJO would be okay, as we're not operating on the data, just representing it differently when asked.
Jason
[ November 18, 2008: Message edited by: Jason Ferguson ]