LA> 1) The actual conversion logic should be implemented in small chunks,
LA> inside the most primitive, bare code-container, interface :
LA> public interface Conversion {
LA> public Object convert(Object value) throws Exception;
LA> }
I agree that the interface should be small, but I am not too sure
about the Exception. Throw-everything forces the caller to
Catch-everything. Maybe a more specific Exception, like
ConversionFailedException, is sufficient.
LA> One implementation should do one simple, well-specified conversion,
[...]
Agreed.
LA> 2) There should be multiple manager classes to implementing distinct
LA> policies for choosing a Conversion. ConversionRegistry will be one
LA> such manager. Other managers may build transitive Conversion chains,
LA> handle inheritance, provide accessors for primitives, etc. Clients
LA> will work with managers, never Conversions themselves. Managers will
LA> wrap exceptions thrown by Conversions in ConversionExceptions. There
LA> is no one interface that could sum up all possible managers.
I also agree very much, but I'd like to see an intermediate structure
to store converters (which I have presented recently as
ConverterRegistry). The managers (ConverterLookup, or however it may
be named) would provide the algorithm to work on the converters.
[snip]
I like the ideas you presented quite a bit. The one thing I don't
understand is how you decide which converter to take. In other words,
why don't you need the input/output type information?
If you want, check out my ideas at
http://www.rblasch.org/convert/convert-docs.zip
http://www.rblasch.org/convert/convert-proto2.zip
Ron
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
