commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <>
Subject Re: [betwixt]:: MixedEncodingStrategy
Date Sun, 04 Apr 2004 09:27:11 GMT
i've committed two new factory constants but i decided against 
renaming. you are right that (on reflection) the choice of name was a 
poor one. i think ContentEncodingStrategy would have been better but 
without a clear leader amongst the others, i think it best not to break 
compatibility for those users who are already using this feature.

- robert

On 27 Mar 2004, at 11:24, George Papastamatopoulos wrote:

> Hey Robert
> I agree with your point regarding the name EncodingStrategy, but i'm
> terrible when it comes to class/interface nameing.  How about 
> something like
> BetwixtEncodingStrategy, RenderingStrategy ?  ...
> Good point regarding the factory class, EncodingStrategyFactory or 
> something
> along those lines makes sense and is clearer than what I suggested.
> Providing default implementations as constants (this is how I actually
> implemented this in my local build) is the way to go.  Makes things 
> simple
> and clear.
> <code>
>   public static final EncodingStrategy DEFAULT = new En....();
> </code>
> I'm a big fan of interfaces (I guess I havn't had too many bad 
> experiences
> with them so far...) I really like the flexibility that interfaces can
> provide.  Imagine this:
> public class MyStupidClassThatAlreadyDoesSomeKindOfXMLProcessing 
> implements
> EncodingStrategy
> Allows me to easily hook into betwixt with minimal fuss and not have to
> worry about extending betwixt's class hierarchy.  No biggie though, I'm
> happy with your suggestion.
> Anyway, that's it from me for now.
> I'm excited about using betwixt in our application!
> Cheers
> george
> -----Original Message-----
> From: robert burrell donkin
> 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:
> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message