commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <robertburrelldon...@blueyonder.co.uk>
Subject Re: [betwixt]:: MixedEncodingStrategy
Date Fri, 26 Mar 2004 23:19:15 GMT
hi george

good to hear from you

On 26 Mar 2004, at 03:05, George Papastamatopoulos wrote:

<snip>

> Just wondering what people thought about the idea of possible breaking
> this out into an interface something along the lines of:
>
> public interface EncodingStrategy {
>  String encode(String, ElementDescriptor);
> }

the MixedContentEncodingStrategy is a logical interface implemented by 
an abstract class.  long (and bitter ;) experience has taught me (and 
many other folks here in the commons) that backwards compatibility 
concerns mean that abstract classes are usual preferable to java 
interfaces for library components.

changing the name of the class is worth considering, though. i couldn't 
think of any other occasion where this would apply but there seemed a 
chance that someday EncodingStrategy might be confusing with something 
like encodings for character data. on reflection, this doesn't seem 
like a very strong argument so i'd be interested to hear any other 
opinions about which is the best name.

> Then could have a static factory class or something similar that would
> create various strategies for us :
>
> public class EncodingStrategies {
>  public static final EncodingStrategy createDefault(){
>    return new DefaultEncodingStrategy();
>  }
>  public static final EncodingStrategy createCData(){
>    return new CDATAEncodingStrategy();
>  }
>  public static final EncodingStrategy createSomeOtherStrategy(){
>    return new SomeOtherClass();
>  }
> }

i do like this kind of construction. i prefer using EncodingStrategies 
for collective classes so i'd probably use the name 
EncodingStrategyFactory. i will add easy constructs for the 
implementations you suggest but there are a few design issues to think 
about.

my thinking about putting the most common implementations in the actual 
abstract class (rather than a separate factory class) is that it should 
be easier for users to find them if they are actually in the 
documentation of the (logical) interface (rather than buried away in a 
factory class). i'd be interested to know whether others share this 
view (or am i just gripped by a fad ;)

the default implementation is obtained as a constant. there is no 
reason why two instances should ever be created and i've been drawn 
towards the opinion that constants communicate this better than factory 
methods but again, i'd be very happy to change to factory method if 
that's more obvious.

> Any thoughts as to whether something like this would be useful?

anyone else want to add their opinions on this?

- robert


---------------------------------------------------------------------
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