I need help!
I'm trying to write a mapped-resource that is a decorator for a
different resource and changes the name of the decorated resource
using a mapper.
Resource itself is a class, so my base class is set. There are
several "optional" behaviors available via interfaces, namely
Touchable, Appendable and FileProvider (I hope I didn't miss one).
Our tasks use instanceof checks in several places, so if the mapped
resource wraps a FileResource it should also implement all three of
those interfaces. OTOH it must not implement any of these interfaces
if wrapping a StringResource.
Any attempt of using anonymous subclasses of MappedResource or
reflection proxies leads to objects that either no longer extend
Resource or contain the methods required by an interface but don't
implement it.
The current solution is really really ugly (seven subclasses with many
of them identical except for the class they extend):
On 2008-11-14, <[EMAIL PROTECTED]> wrote:
>> public static MappedResource map(Resource r) {
>> if (r instanceof FileProvider) {
>> if (r instanceof Touchable) {
>> if (r instanceof Appendable) {
>> // most probably FileResource
>> return new AppendableTouchableFileProviderMR(r);
>> }
>> return new TouchableFileProviderMR(r);
>> }
>> if (r instanceof Appendable) {
>> return new AppendableFileProviderMR(r);
>> }
>> return new FileProviderMR(r);
>> }
>> if (r instanceof Touchable) {
>> if (r instanceof Appendable) {
>> return new AppendableTouchableMR(r);
>> }
>> return new TouchableMR(r);
>> }
>> if (r instanceof Appendable) {
>> return new AppendableMR(r);
>> }
>> // no special interface
>> return new MappedResource(r);
>> }
The other approach I could take is to clone the wrapped resource (all
our resources are cloneable) and change the clone's name - and not
have a decorator at all.
The main problem with this approach is that some resources are
immutable and will throw an exception in setName (StringResource for
example) while others will not do what I want - FileResource will
simply ignore setName().
Any other ideas (apart from not using Java?)
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
