Overriding a single interface method when the implementing class is sealed

This is probably easiest to explain with code (this is of course not the actual code but it has the same properties):

I have an interface that looks something like this:

    public interface ISomeProvider
    {
        object GetFoo1(); //<-- This needs caching

        //These others don't
        object GetFoo2();
        object GetFoo3();

        //And let's say 20 more
    }

And this has an implementation like this:

    //NOTE: Sealed class otherwise we could inherit from it
    public sealed  class SuperCleverProvider : ISomeProvider
    {
        public object GetFoo1()
        {
            return "a";
        }

        public object GetFoo2()
        {
            return "b";
        }

        public object GetFoo3()
        {
            return "b";
        }
    }

Now one of these calls, let's say GetFoo1 is really heavy so I want to provider a new version of the interface where calls to it are cached using an instance of the old one.

I'm doing it like this at the moment:

    public class CachedSuperCleverProvider : ISomeProvider
    {
        private readonly SuperCleverProvider _provider;

        public CachedSuperCleverProvider(SuperCleverProvider provider)
        {
            _provider = provider;
        }

        private object UsingCache<T>(string cacheKey, Func<T> eval)
        {
            //Pretend this does caching. This is not related to the question
            throw new NotImplementedException();
        }

        public object GetFoo1()
        {
            return UsingCache("foo1", _provider.GetFoo1);
        }

        //The code below this point is what I want to get rid of
        public object GetFoo2()
        {
            return _provider.GetFoo2();
        }

        public object GetFoo3()
        {
            return _provider.GetFoo3();
        }

        //And so on for all the rest
    }

This has two problems (at least):

• Every time someone adds a method to the interface I have to go change this even though I dont want this new method to be cached
• I get this huge list of useless code that just call through to the underlying implementatio开发者_运维问答n.

Can anyone think of a way of doing this that doesn't have these problems?

---

Three options:

• Autogenerate the class
• Use PostSharp or something similar to do it in a more interceptor-based way
• Live with it

Personally I'd probably go with the third option, unless you really find yourself doing this a lot. Weigh up the cost of each option - how much time are you actually going to spend adding this delegation?

Personally I'd like to see this sort of thing as a language feature - "delegate to this interface via this field unless I override it" but obviously that's not present at the moment...

---

Here's what I'd suggest. It's not too much better, but will simplify the wrapping process.

Create a class SomeProviderWrapper:

public class SomeProviderWrapper : ISomeProvider
{
    protected ISomeProvider WrappedProvider { get; private set; }

    protected SomeProviderWrapper(ISomeProvider wrapped)
    {
        if (wrapped == null)
            throw new ArgumentNullException("wrapped");

        WrappedProvider = wrapped;
    }

    public virtual object GetFoo1()
    {
        return WrappedProvider.GetFoo1();
    }

    public virtual object GetFoo2()
    {
        return WrappedProvider.GetFoo2();
    }

    public virtual object GetFoo3()
    {
        return WrappedProvider.GetFoo3();
    }
}

Now that the wrapping is relegated to its own class, you can write the caching version:

public class CachedSuperCleverProvider : SomeProviderWrapper
{
    public CachedSuperCleverProvider(ISomeProvider wrapped) : base(wrapped) { }

    private object UsingCache<T>(string cacheKey, Func<T> eval)
    {
        throw new NotImplementedException();
    }

    public override object GetFoo1()
    {
        return UsingCache("foo1", WrappedProvider.GetFoo1);
    }
}

This keeps the delegation code out of your super clever provider. You will still have to maintain the delegation code, but it won't pollute the design of your caching provider.