- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
