Generic Constraints vs. Inheritance

Question

I'm trying to write some code to help unit test WCF services. These services are accessed through a facade class that creates the proxy instance, then calls the proxy method and returns the result; for each proxy method. I'd like to be able to replace the current creation code with something that either creates the real service or a fake one.

I couldn't get that to work. I boiled it down to the following:

using System.ServiceModel;

namespace ExpressionTrees
{
    public interface IMyContract
    {
        void Method();
    }

    public class MyClient : ClientBase<IMyContract>, IMyContract
    {
        public MyClient()
        {
        }

        public MyClient(string endpointConfigurationName)
            : base(endpointConfigurationName)
        {
        }

        public void Method()
        {
            Channel.Method();
        }
    }

    public class Test
    {
        public TClient MakeClient<TClient>()
            where TClient : ClientBase<IMyContract>, IMyContract, new()
        {
            return new MyClient("config");

            // Error:
            // Cannot convert expression of type 'ExpressionTrees.ServiceClient' to return type 'TClient'
        }
    }
}

Why is it that, even though the MyClient class derives from ClientBase<IMyContract> and implements IMyContract, that I can't return a MyClient instance from a method meant to return a TClient? TClient specifies a type constraint I had thought meant the same thing.

---

My goal was to call code like this:

    public void CallClient<TClient>()
        where TClient : ClientBase<IMyContract>, IMyContract
    {
        TClient client = null;
        bool success = false;
        try
        {
            client = MakeClient<TClient>();
            client.Method();
            client.Close();
            success = true;
        }
        finally
        {
            if (!success && client != null)
            {
                client.Abort();
            }
        }
    }

But instead of always calling MakeClient<TClient>, I wanted to be able to have a unit test inject a mock object. Since the code above depends both on ClientBase<IMyContract>, IMyContract, it seems I was trying to "synthesize" a generic class that would satisfy that constraint.

In retrospect, this wouldn't make sense. As an example, the ClientBase<IMyContract> would expect to be instantiated in such a way that a Channel object would be constructed that it could then delegate the Close method to.

I've wound up punting on having the exact same code run both for the real and for the fake services. I'm now injecting an IMyService, and either calling IMyService.Method or client.Method depending on whether my injected property is null.

Thanks for the suggestions, which showed me where my thinking was wrong.

Answer 1

You are restricting the TClient in the MakeClient<TClient>() portion of the call, not the return type.

The return type has to match the type of the generic parameter, but picture this:

public class MyOtherClient : ClientBase<IMyContract>, IMyContract
{
    public void Method()
    {
        Channel.Method();
    }
}

That's also a valid return by calling MakeClient<MyOtherClient>, which MyClient is not convertable to, since it should return a type of MyOtherClient.

Note that changing the return to:

return new MyClient() as TClient;

would probably get it past the compiler, but be null in my scenario above at runtime.

Answer 2

This should resolve your issue.

static T Make<T>() where T : IConvertible
{
    var s = "";
    return (T)(Object)s;        
}

Answer 3

Basically your code boils down to:

    public static T MakeFruit<T>() where T : Fruit 
    { 
        return new Apple(); 
    } 

This always returns an apple, even if you call MakeFruit<Banana>(). But MakeFruit<Banana>() is required to return a banana, not an apple.

The meaning of the generic type constraint is that the type argument provided by the caller must match the constraint. So in my example, you can say MakeFruit<Banana>() but not MakeFruit<Tiger>() because Tiger does not match the constraint that T must be convertible to Fruit. I think you believe that the constraint means something else; I'm not sure what that is.

Think about it like this. A formal parameter has a formal parameter type. The formal parameter type restricts the type of the expression that is used as an argument. So when you say:

void M(Fruit x)

you are saying "the argument passed for formal parameter x in M must be convertible to Fruit".

Generic type parameter constraints are exactly the same; they are restrictions on what type arguments may be passed for the generic type parameters. When you say "where T : Fruit", that is just the same as saying (Fruit x) in the formal parameter list. T has got to be a type that goes to Fruit, just as the argument for x has got to be an argument that goes to Fruit.

Why do you even want to have a generic method in the first place? I don't understand what exactly you're trying to model with this method or why you want it to be generic.