我们在开发时往往会对泛型指定约束条件，只有类型参数符合条件的才允许用在这个泛型上面。但是有时我们会定义过多或过少的约束条件，过多的约束条件会导致其他开发人员在使用你所编写的方法或类时做很多的工作以满足这些约束，过少的约束又会导致程序在运行的时候必须做很多的检查，并执行更多的强制类型转化操作，有时我们还需要使用反射生成运行期错误，来防止用户误用这个类。要解决这些问题，我们就必须把确实需要的约束写出来，这句话说起来简单，其实做起来不太容易。下面我就来讲解一下如何正确的编写一个规范的约束。
零、简述
何为约束？所谓约束就是使得编译器能够知道 类型参数 除了具备 System.Object 所定义的公共接口外还需要满足的条件。在创建泛型类型时编译器必须为这个泛型类型定义有效的 IL 码，即使它不知道其中的类型参数会在什么时候替换成什么类型，也会设法创建出有效的程序集。如果我们不给它指明类型参数，那么它就会默认设置类型参数是 System.Object 类型。我们通过约束来表达对泛型类型的类型参数的约束要求会营销编译器和使用这个类的开发人员。编译器看到我们指定的约束后就会明白除了除了具备 System.Object 所定义的公共接口外还需要满足什么条件。对于编译器来说它获得了两个帮助：
- 可以令编译器在创建这个泛型类型的时候获得更多的信息；
- 编译器能够保证使用这个泛型的开发人员所提供的参数类型一定满足我们所指定的条件。
一、如何规范约束条件
讲解之前我们先来看一个例子，这个例子判断了输入的两个值是否相等。
public bool DemoEqual<T>(T t1, T t2)
{
if(t1==null)
{
return t2==null;
}
if(t1 is IComparable<T>)
{
IComparable<T> val1 = t1 as IComparable<T>;
if(t2 as IComparable<T>)
{
return val1.CompareTo(t2)==0;
}
else
{
throw new ArgumentException($"{
nameof(t2)} 没有实现 IComparable<T>");
}
}
else
{
throw new ArgumentException($"{
nameof(t1)} 没有实现 IComparable<T>")
}
}
这段代码中执行了大量的强类型转换，在转换之前还判断时传入的参数是否实现了 IComparable 接口。这段代码如果使用了泛型约束就会很简单：
public bool DemoEqual<T>(T t1, T t2)
where T : IComparable<T>
=> t1.CompareTo(t2)==0;
这段代码大大简化了前面的那段代码，并且把程序运行期可能出现的错误提前到了编译期，编译器提前阻止了不符合要求的用法。到这里你是不是以为上述代码就是很好的解决方案呢？其实严格来说上述代码矫枉过正了，为什么这么说呢？因为 IComparable 接口很常见，大部分开发人员在设计类型的时候都会事先这个接口，因此我们将上述代码修改一些，我们不使用 CompareTo 来对比两个值是否相等，我们这次使用 Equals 来对比:
public bool DemoEqual<T>(T t1, T t2)
=> t1.Equals(t2);
上述代码有一点需要注意，如果 DemoEqual 是定义在泛型类里，并且泛型类也规定了 IComparable 约束，那么他调用的 Equals 是 IComparable.Equals ，反之调用的就是 System.Object.Equals 。这两个 Equals 在性能上没什么大的差别，前者的执行效率只比后者高了那么一丢丢，因为它只是不用在运行时检查程序有没有重写 System.Object.Equals ，以及泛型参数类型为值类型时它也不用执行装箱和拆箱操作。但是对于把性能看的特别重的开发人员来说，前者是最优的方案。
Tip：如果有较好的方法，我还是建议大家使用较好的方法，比如前面我们所说的 IComparable.Equals 。
我们在编写泛型类的时候，最好在内部编写相互重载的多个方法，这样就可以针对不同的情况调用不同的方法，并且其他开发人员调用起来也不会有过于严谨的约束。有时候我们定义的约束过于严谨，会导致泛型类的适用范围很狭窄，遇到这种情况时我们就应该考虑我们自己在泛型类种编写代码来判断传入的类型是否继承自某个类或者实现了某个接口。在泛型约束中有三种约束我们必须谨慎使用，它们就是 new 、 struct 以及 class 约束，因为它们会限定对象的构建方式，除非你要求对象的默认值必须是 0 、null 或者必须能以 new() 的形式创建，那么我们才可以使用这三种约束。
二、总结
约束是为了向调用方提出要求，但是如果约束太多调用方就需要做更多的工作来满足这些约束，因此在创建约束时应该权衡利弊，将多余的约束去掉只保留需要的约束。
发布者：全栈程序员-站长，转载请注明出处：https://javaforall.net/182362.html原文链接：https://javaforall.net
