Greetings All
I have been corresponding with Stephen regarding some design decisions
being made in [convert]. I'd like to make a couple of pugnacious
declarations and hope that ensuing discussion generates good ideas and
consensus.
I'll first state my beliefs, then I'll try to justify them belief at
great length :-)
1) The actual conversion logic should be implemented in small chunks,
inside the most primitive, bare code-container, interface :
public interface Conversion {
public Object convert(Object value) throws Exception;
}
One implementation should do one simple, well-specified conversion,
e.g. String to Integer. The implementation should be free to make
documented assumptions about its input and free to throw any exception
if an assumed precondition is broken.
2) There should be multiple manager classes to implementing distinct
policies for choosing a Conversion. ConversionRegistry will be one
such manager. Other managers may build transitive Conversion chains,
handle inheritance, provide accessors for primitives, etc. Clients
will work with managers, never Conversions themselves. Managers will
wrap exceptions thrown by Conversions in ConversionExceptions. There
is no one interface that could sum up all possible managers.
I recently implemented a framework similar to [convert], also inspired
by the limitations of BeanUtils. The framework evolved to support a
large (1.5m lines) family of business applications. The result of the
painful evolution was what I described above.
For example, having the concepts of "from type" and "to type" near the
core of the framework proved unhelpful.
One use case where this broke down was this :
Legacy business objects often use java.util.Date to represent any or all
of a) bare date b) bare time c) date-time. Therefore in flattening the
properties of such objects to text three different rules are applied for
the java.util.Date -> java.lang.String conversion.
By eliminating the "from type"/"to type" concept from the core, this use
case can be handled cleanly. It requires a simple manager semantic that
associates a Conversion with a Method or property name.
Another use case forced the simplification of the Conversion interface :
There are cases where a Conversion is highly customized or involves
non-public types. Being able to implement it as an anonymous class
is very important.
registry.register(GUID.class, new Converter() {
protected Object convert(Object value) {
String string = value.toString();
return new GUID(string.startsWith("0x") ? string.substring(2) : string);
}
});
This code snippet deals with a quirk of a minor legacy API that may or may
not add a "0x" prefix to hexadecimal values. If it were hard to implement
the rule in-line, clients would've opted to hack around the conversion
framework, sharply reducing its value.
I am currently negotiating with my employer to release the code to Jakarta.
Hopefully it will help generate some more ideas.
Andrei
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
