I have a generic interface for a mathematics library, something like this:
[ContractClass(typeof(MathsDoubleContracts))]
public interface IMaths<T>
{
T SomeFunction(T n);
}
This enables me to create an IMaths<double>, IMaths<decimal>, etc. (although at first I only need the double version).
I’d like to set up code contracts. At present I’ve done this:
[ContractClassFor(typeof(IMaths<double>))]
public abstract class MathsDoubleContracts : IMaths<double>
{
public double SomeFunction(double n)
{
// Always positive
Contract.Ensures(0 <= Contract.Result<double>());
return double.NaN;
}
}
This seems to work, but I’m rather surprised that it does (given that I’m specifying contracts on IMaths<double> rather than IMaths<T>).
I’m left wondering:
- Can I specify multiple contract classes on a generic interface, one for each specific type I want to use (e.g. have both
[ContractClass(typeof(MathsDoubleContracts))]and[ContractClass(typeof(MathsDecimalContracts))]attributes onIMaths<T>)? Is this a sensible thing to do? - Would I be better off not using generic interfaces at all (i.e. start with, say,
IMathsDoublewhere all the functions are defined in terms of doubles, addingIMathsDecimallater)?
Q1
Can you bring an example please.
EDIT
No. It does not allow multiple. Ref here.
Note
AllowMultiple = false.Q2
Yes, although generics might provide some little benefit. Your interface is not really generic. I cannot use
IMaths<File>for example. I actually answered a different but related question here.You may add restrictions such as
where T : ...but that also will not do since you have to limit to onlyint,doublewhile you can only dowhere T : structwhich is not the same thing. Here generics is mere a decoration and the abstraction ofIMaths<T>cannot be used as it is (or can it? can depend on your code) and you need concrete classes or interfaces.A sub-interface is a safe option here