C#中==操作符存在的缺陷

  ==操作符因为语法简洁而备受欢迎,但它本身也存在着局限性,比如继承或泛型问题。下面让我们依次来看看吧。

1、==和继承性问题

  关于==运算符在继承时存在的问题,我们以String类型为例进行说明。

 static void Main(string[] args)
        {
            string str = "hello";
            string str1 = string.Copy(str);

            Console.WriteLine(ReferenceEquals(str, str1));
            Console.WriteLine(str.Equals(str1));
            Console.WriteLine(str == str1);
            Console.WriteLine(object.Equals(str, str1));
            Console.Read();
        }

  运行上面代码,依次产生:False、True、True、True。该结果很容易解释,除了ReferenceEquals方法进行引用比较之外,其他三种比较方法均是值比较。

  现在让我们稍微修改一下上述代码,如下所示:

static void Main(string[] args)
        {
            Object str = "hello";
            Object str1 = string.Copy(str);

            Console.WriteLine(ReferenceEquals(str, str1));
            Console.WriteLine(str.Equals(str1));
            Console.WriteLine(str == str1);
            Console.WriteLine(object.Equals(str, str1));
            Console.Read();
        }

   再次运行上面代码,结果为:False、True、False、True。和上面的结果进行比较,可以发现,只有==操作符的结果发生了改变,这是为什么呢?

  原因就在于==相当于一个静态方法,而静态方法不可能是virtual的,本例中当用==进行比较时,比较的是两个Object类型的变量,尽管我们知道str和str1实际是String类型的,但编译器并没有意识到这一点。我们应该牢记的一点就是:对于非虚方法的调用而言,具体调用哪个实现是在编译时期就已经做出决定了。具体到我们的例子,就是说,我们声明了Object类型的两个变量str和str1,那么编译器就会生成比较Object类型的代码。而Object类中是没有==操作符的重载版本实现的,因此,==将进行引用相等性比较,因str和str1是两个不同的实例对象,故返回False。

  由于在面临继承时的无能为力,故此是不应选择==,而应使用Equals方法进行判等。接下来看一下Equals方法是如何解决这个问题的。

  显然,当使用Equals方法进行判等测试时,无论调用的是str.Equals还是object.Equals方法,最终调用的都是String类型的override版本实现,故总能计算出我们预期的结果。因此,在存在继承问题时,应使用Equals方法进行判等,而不是==操作符。

  最后,从本例中可以看到,当我们将==操作符的操作数强转到Object类型时,它将进行引用相等性测试,总是和ReferenceEquals的结果保持一致,因此,一些开发者就使用这种方式来比较引用相等性,但这样做的一个缺点在于:其他的开发者在读到这样的代码片段时可能产生疑惑。因此在比较引用相等性时最好总是使用ReferenceEquals方法。

2、==和泛型问题

  ==的另一个缺陷就是不能和泛型很好地工作在一起。考虑下面的代码:

static void Equals(T a, T b)
{
    Console.WriteLine(a == b);
}

   上面代码的逻辑很简单,就是使用==比较两个T类型的对象。但是编译上述代码将报错:

  之所以报上面的错误,是因为T可能代表任意类型,包括基元类型、值类型和引用类型。无法确定传递的类型是否实现了==操作符重载。

  在C#中,对于泛型类型,我们无法施加这样的约束,即强制要求传入的泛型类型T实现==的重载。

  现在,我们能够构建代码,仅有的一个问题就是:Equals被限定在仅能接受引用类型,而不能接受值类型。

  现在,让我们还是以之前的字符串比较为例,

class Program
{
    static void Main(string[] args)
    {
        Object str = "hello";
        Object str1 = string.Copy((string)str);

        Equals(str, str1);
    }

    static void Equals(T a, T b) where T : class
    {
        Console.WriteLine(a == b);
    }
}

  现在,猜测一下上面代码的输出结果,是true还是false ?如果我们回想起String类型定义了==操作符的重载实现,那么很可能猜测上面代码的结果为true,但实际运行结果却显示false,这是为何呢?此时很直观的猜测就是==操作符计算的是引用判等,而非值判等。下面让我们看看究竟发生了什么。

  上面的代码中,尽管通过where T : class语句限定使得编译器知道它能对传入的任何类型应用==操作符进行判等性测试,对应到本例T就是String类型,而且String类型提供了==的重载实现,但编译器并不晓得泛型类型T是否重载了==操作符,因此,它假定T没有重载==。编译器编译代码时假定调用的是Object基类==操作符,因此,==操作符进行引用判等性测试。

  应该始终牢记一点:在对泛型类型T使用==操作符时,编译器不会使用类型T定义的==运算符重载,相反,它会将T视为Object类型,并调用Object基类的==操作符方法。

  接下来让我们看下Equals方法如何解决上面的问题。

static void Equals(T a, T b)
{
   Console.WriteLine(object.Equals(a,b));
}

   可以看出,我们移除了泛型方法的class限定语句,因为能在任何类型上调用Object.Equals方法,之所以使用static限定,是为了避免发出调用的实例对象为null,可以看出上面的泛型方法对值类型和引用类型均奏效。

  我们再次运行上面的代码,结果显示True。这是因为Object.Equals方法在运行时将调用它的override版本实现,本例中override版实现的定义位于String类型中,该实现进行值判等性测试。

转载于:https://www.cnblogs.com/lian--ying/p/9537711.html

你可能感兴趣的:(c#)