> * It uses two params and not a return value to make it usable with
> * event based Objects (contenthandlers).
> * Events in the Morpher are notified by registering a listener.
> * [new] parameters are managed with beans get/set methods
> * *none* are mandatory
> */
> public interface Morpher {
> void morph(Object input, Object output) throws MorphException.
> [Clarification]
> Why not
> Object morph(Object input) throws MorphException, IOException;
> ?
> Because if the output object is a SAX handler, the morphing doesn't take
> place, and this is not evident.
> Any other pros-cons?
The problem with the two object input approach is that it precludes a simple
type convertor being written using this architecture. A type convertor
typically takes in an immutable object and returns an imutable object
(String/Integer etc.)
Object morph(Object input) does allow a String to Integer convertor, but
is obviously a second interface, potentially providing confusion.
Given this, you may want to refine the definition of what can or can't be
morphed (ie. to exclude immutable outputs).
Stephen
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
