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]
