Stephen,
I had a first look at both code bases. From the underlying concepts both
seem to be very similar: they both have a basic interface describing a
conversion/converter, factories for converters and a registry mechanism.
This said it is quite hard to judge, which implementation should be
preferred.
In convert2 I like the Converter class, which is an additional
encapsulation of a registry. From a semantic point of view it is
certainly better to use a "Converter" for conversions than a
"ConvertRegistry" as in convert1. On the other hand I have some problems
to see the benefits of the convert2.ConversionFactory: Because a factory
is used only once to obtain a Conversion for a to/from class
combination, there are not many advantages over using a Conversion
object directly (I think it would be more flexible if the Conversion
returned by a factory would not be stored; then a factory could return
different objects based on the actual value). (And one minor detail: I
think the first method in ConvertUtils should be named convert() and
perform a default conversion rather than a String conversion.)
The convert1 package has the advantage that it partly deals with
inheritence, which can be useful. Though when looking at the code I am
not sure that the current implementation will work. Because the
Converter interface is very simple it seems to be easier to implement
concrete converters. In the available implementations I would somehow
try to refactor out the handling of default values, maybe as a kind of
decorator converter.
What I miss in both approaches is a more intuitive setup mechanism, a
simple way to construct a registry from available converter
implementations, though I don't have a concrete idea how to improve this
either. Would it make sense to construct a default registry from a
configuration file? Is it perhaps possible to use [discovery] to find
converter implementations (I don't know this project very good).
Another suggestion: Depending on the actual use case it might make sense
if a failing conversion throws a checked exception rather than a runtime
exception, e.g. when used to validate user input. So it could be useful
to add methods that throw an exception and let the client choose.
Oliver
Stephen Colebourne wrote:
>I have just checked in a load of new commits in the convert2 subpackages.
>Essentially there are now two convert codebases in CVS, Henri committed the
>first based on [beanutils] IIRC, whereas I've developed the second. An
>external review would be good. If you could take a look at both and see what
>you like that would be great ;-)
>
>Once one is picked, we can then get on and add more converters and tests,
>and then maybe look to a release. I'd like an early promote and release if I
>can manage it.
>
>Stephen
>[
>Notes about convert2 package:
>System is bean based - different applications can have different converters.
>Each individual conversion is an implementation of a simple interface
>Conversion.
>The combination of a group of Conversions is a Converter.
>A ConversionFactory allows Conversions to be dynamically created.
>Main conversion registry is fully synchronized (as double check locking
>broken).
>]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
|