commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Legostaev, Andrei" <Andrei.Legost...@gs.com>
Subject [convert] Use cases not currently covered
Date Mon, 22 Mar 2004 18:55:59 GMT

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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message