commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver.He...@t-online.de (Oliver Heger)
Subject Re: [convert] Designs [was Another use case]
Date Sun, 07 Mar 2004 18:57:01 GMT
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


Mime
View raw message