简体   繁体   中英

Force generic type parameter

I'm building a HTTP-API wrapper for .NET, which has a bunch of methods to set data in an object, and then it serializes the data and sends it to my server. There are 6 datatypes allowed:

  • string
  • int
  • long
  • float
  • double
  • DateTime

My data attributes use generics:

SetAttribute<T>(string key, T value)

So there is only one generic method to set data. Since I cannot constrain the data types to the 6 mentioned, I use run-time checks and throw an exception when the wrong data type is used.

Now for my problem: I have two versions of SetAttribute, one that takes a single value (of type T) and one that takes multiple values (of type IEnumerable<T>). The problem is that when a programmer uses this wrapper and does not specify the type parameter, the runtime guesses which method to use, for instance:

SetAttribute("testkey","thing,anotherthing,athirdthing".Split(','))

This defaults to the single value method and T is String[] which of course makes my method cast an exception because String[] is not a valid type. If you specify:

SetAttribute<string>("testkey","thing,anotherThing,aThirdThing".Split(','))

The runtime chooses the correct method (multi-value) and no exception is cast because T is then string.

My question: how can I label my methods so that the type parameter is mandatory and must be explicitly defined? Or do I have to detect this at runtime and redirect to the multi-method myself?

Given a parameter type, the compiler finds a best match from your overloads. If you cast your string[] to an IEnumerable<string> you will probably find it works as expected because the best match is a method that has exactly those parameters. But you have no method that takes a string[] , so given one as a parameter, the compiler makes the best guess it can.

I would have two separately named methods rather than overloads otherwise it is too easy to run into this problem. Or have 6 separate overloads, as @Joachim suggests.

Ok, this was originally a comment above since it doesn't necessarily answer your original question but suggests an alternate approach;

I would say using a public generic SetAttribute in this case isn't necessarily a good idea.

Since the types are so constrained, you should probably just write the overloads and move the errors from runtime to compile time. It would also allow you to take IEnumerable<string> etc. with another 6 overloads and eliminate the problem you're having entirely.

You can always implement SetAttribute with a private generic and just call that from each overload, that will remove some duplication.

It will also more or less eliminate the need for runtime checks, since the types are already constrained by the compiler.

One solution would be to break your original method into 6 non-generic overloads, and add another generic overload for collections:

void SetAttribute(string key, int value);
void SetAttribute(string key, string value);
// etc

// abd this takes care of collections:
void SetAttribute<T>(string key, IEnumerable<T> value);

I would suggest a better solution would be to test whether the value passed in is IEnumerable after it fails everything else and treat it as such if it is. (I imagine that you're handling IEnumerable as a seventh case already).

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM