规范约束条件

简介: 规范约束条件

我们在开发时往往会对泛型指定约束条件,只有类型参数符合条件的才允许用在这个泛型上面。但是有时我们会定义过多或过少的约束条件,过多的约束条件会导致其他开发人员在使用你所编写的方法或类时做很多的工作以满足这些约束,过少的约束又会导致程序在运行的时候必须做很多的检查,并执行更多的强制类型转化操作,有时我们还需要使用反射生成运行期错误,来防止用户误用这个类。要解决这些问题,我们就必须把确实需要的约束写出来,这句话说起来简单,其实做起来不太容易。下面我就来讲解一下如何正确的编写一个规范的约束。


零、简述

何为约束?所谓约束就是使得编译器能够知道 类型参数 除了具备 System.Object 所定义的公共接口外还需要满足的条件。在创建泛型类型时编译器必须为这个泛型类型定义有效的 IL 码,即使它不知道其中的类型参数会在什么时候替换成什么类型,也会设法创建出有效的程序集。如果我们不给它指明类型参数,那么它就会默认设置类型参数是 System.Object 类型。我们通过约束来表达对泛型类型的类型参数的约束要求会营销编译器和使用这个类的开发人员。编译器看到我们指定的约束后就会明白除了除了具备 System.Object 所定义的公共接口外还需要满足什么条件。对于编译器来说它获得了两个帮助:


  1. 可以令编译器在创建这个泛型类型的时候获得更多的信息;
  2. 编译器能够保证使用这个泛型的开发人员所提供的参数类型一定满足我们所指定的条件。

一、如何规范约束条件

讲解之前我们先来看一个例子,这个例子判断了输入的两个值是否相等。

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() 的形式创建,那么我们才可以使用这三种约束。

二、总结

约束是为了向调用方提出要求,但是如果约束太多调用方就需要做更多的工作来满足这些约束,因此在创建约束时应该权衡利弊,将多余的约束去掉只保留需要的约束。


目录
相关文章
|
17天前
|
编译器 API C++
c++ 新特性 概念和约束 “无规矩 难成方圆”
c++ 新特性 概念和约束 “无规矩 难成方圆”
|
1天前
|
XML 安全 前端开发
W3C规范的重要性是什么?
【6月更文挑战第1天】W3C规范的重要性是什么?
10 4
|
3天前
|
安全 API Apache
实现一个好的服务接口的准则
【5月更文挑战第20天】本文介绍 REST API 实现技巧。包括以下具体内容,实现HTTP处理器、 实现版本控制; 用JSON格式,遵循HTTP方法规范;语义化命名;强调安全性;采用版本控制;保持一致性;支持错误处理;接口智能化处理业务逻辑;性能优化;健壮性的实现等。通过以上步骤,创建安全、高效、易用的REST API,促进团队合作和生态系统健康发展。 6
19 3
|
11月前
|
存储 搜索推荐 开发工具
怎么去约束代码的统一性
当你着手的项目随着协同人员的越来越多,始终会面临着一个问题,那就是代码的统一性,俗话说,千人千面,放在代码里,也是百家争鸣,毕竟每个人都有自己的思想,也有着自己书写代码的风格,如何让一个项目,朝着一个统一的风格前去,这个是很难的,难的不是规范的制定,而是规范的落实。
|
10月前
|
机器学习/深度学习 算法 决策智能
约束最优化方法 (三) 外部罚函数法
约束最优化方法 (三) 外部罚函数法
约束最优化方法 (三) 外部罚函数法
|
11月前
|
API
使用的orTools的约束规划与线性规划解决相同问题的代码api差异对比
使用的orTools的约束规划与线性规划解决相同问题的代码api差异对比
75 0
|
测试技术
测试思想-流程规范 用例优先级定义与使用规范 V1.0
测试思想-流程规范 用例优先级定义与使用规范 V1.0
107 0
|
测试技术 程序员 项目管理
测试思想 测试术语定义
测试思想 测试术语定义
69 0
|
存储 SQL BI
数据字典标准与统一的重要性(码表&枚举值)
关于“公共代码、编码、码表、枚举值”的含义,以及在软件开发中的应用场景。
311 0
数据字典标准与统一的重要性(码表&枚举值)
选择正确的错误度量标准:MAPE与sMAPE的优缺点
选择正确的错误度量标准:MAPE与sMAPE的优缺点
696 0
选择正确的错误度量标准:MAPE与sMAPE的优缺点

热门文章

最新文章