细数我不喜欢的C#语言中的特性

C#确实是一个好语言,无论是从功能上还是性能上。但是用久了难免会发现并吐槽其中的一些SB设计。如果是稍微难用点(比如语法复杂点、调用麻烦点)那倒无所谓,但如果是为以后的bug开坑那就是不好的东西了,这里记录几个我最近发现的不爽的地方吧。

 

1. 支持协变数组

个人认为协变和逆变是面向对象编程语言中一个很好的特性。

比如我定义了一个哺乳动物Mammals类和狗Dog类(Dog继承自Mammals),那么假如我有一个以返回值为Mammals的委托,那么实际上返回值为Dog的方法是可以添加到委托里的。——这很自然,Dogs肯定包含了Mammals的所有定义。

反过来,假如我想要写一个通用的方法处理控件的各类事件,我可以这样定义方法:

private void MultiHandler(object sender, System.EventArgs e)
{

}

这个方法就能和各类事件比如MouseClick和KeyDown关联上:

public Form1()
{
    InitializeComponent();

    this.textBox1.KeyDown += this.MultiHandler; //works with KeyEventArgs
    this.button1.MouseClick += this.MultiHandler; //works with MouseEventArgs

}

 

但是,这个特性不是到处都有用的。比如C#支持数组的协变,那么假如我定义了下面这两个类:

    class Father
    {
        public string Name { get; set; }
    }

    class Child : Father
    {
        public int Age { get; set; }
    }

我就可以把一个类型为Child的数组传递给一个类型为Father的数组引用:

            Father[] f;
            Child[] c = { new Child { Name = "JDP", Age = 24 }, new Child { Name = "ABC", Age = 2 } };

            f = c;

初看似乎没什么问题,至少这样很灵活么?但是如果f这个变量是公用的,有好几个程序员都在用这个变量。那么很有可能有些人不知道f里面实际上是一个Child的数组(因为定义是Father),所以他把一个Father的对象放入数组中:

            f[1] = new Father { Name = "XXY" };

因为运行时的类型是Child[],那么这么做自然是不被允许的:

QQ截图20131220214047

这就很令人莫名其妙,而且错误只有在运行时才会产生,编译过程中不会出错(因为C#认为f是Father[],它不知道具体的运行时类型)。

其实.NET最初设计的时候,看到Java支持这个特性,所以就照搬了过来,目测是更多地“吸引”Java程序员并符合他们的习惯。在Java中这应该也是一个缺陷之一。

不过还好,.NET里面的泛型类是不支持这种协变的,比如我定义了一个List<object>,那么我是不能传递一个List<string>类型的实例对象的,在编译的时候就会被阻止:

QQ截图20131220214047

要在泛型类中使用协变,需要借助接口的方差参数,比如IEnumerable的定义如下:

public interface IEnumerable<out T> : IEnumerable

在方差中使用out关键字,表示输出类型允许协变,这样下面的代码是合法的:

IEnumerable<Derived> d = new List<Derived>();
IEnumerable<Base> b = d;

无论如何,数组的协变是不合理的,而且与泛型的表现不一致,所以是C#的一大弊端。

 

2. 支持非虚方法

非虚方法是C#从C++抄过来的特性(毕竟都有C这个字母嘛,所以要像一点)。任何没有virtual关键字修饰的方法都是非虚的,子类不可以重写。

要是光是不能被重写,那还可以接受,但是C#偏偏支持方法的“遮蔽”new关键字,让子类把父类的相同签名的方法“隐藏”起来,这就让人很迷惑了——调用者甚至都不清楚自己到底是调的哪个方法。

C#是类型安全的编程语言,任何类型都无法伪装成另一种类型。这是为什呢?我们来看看Object类的定义:

QQ截图20131220214047

可以看到,在实例方法中除了GetType以外,其他方法都是虚方法。那么就意味着GetType方法不允许被子类重写。Object类的GetType方法是CLR的内部方法,返回一个对象的具体类型(也就是一个Type类型的引用)。子类无法重写GetType方法,那么自然没有办法宣称自己是一个其他的类型——因为调用Object的GetType就知道真实的类型了。

但是有一点很容易被忽略:虽然GetType是非虚的,但是子类可以把它“遮蔽”掉,比如我是这样写一个类:

    class Father
    {
        public string Name { get; set; }

        public new Type GetType()
        {
            return typeof(String);
        }
    }

我想把自己“伪装”成String类,那么下面代码输出什么呢?

            Father fat = new Father { Name = "Xiaoyu" };
            Console.WriteLine(fat.GetType());

你答对了,自然是System.String。那么如果我们要获取其真实的类型那就要保证调用到Object的GetType方法。由于是非虚的,那么理论上要把fat对象放到一个object的引用里面去:

            object o = fat;
            Console.WriteLine(o.GetType());

这样子才能保证调用到Object的GetType方法。Microsoft似乎发现了这个问题,所以它提供了typeof运算符。

GetType只是一例,稍不留神就可能发生错误。那么其他自己写的方法就更加可能产生问题了。

Java就很好,干脆所有的方法都是虚方法,这样就完全没有C#的这种问题。此外,假如Java也使用GetType来获取类型,那它应该怎么样防止子类重写呢?哈哈,Java有final修饰符(.NET中方法的sealed修饰符只能把虚方法和虚属性的方法密封,所以GetType无法添加sealed修饰符)。

 

3. IEnumerable扩展方法的滥用

IEnumerable接口上的扩展方法是LINQ的基础,也是一个比较好用的工具。但是扩展方法很容易被不恰当地“滥用”——因为它实在是太方便了。而且,它的使用屏蔽掉了不该屏蔽的一些“实质”。

举一个比较极端的例子,我定义了一个ConcurrentQueue,里面有一堆的元素。但是队列嘛,一般只支持查看队首的元素,假如由于某种需求我需要查看其中所有的元素(这是前两个月我做的一个产品中的需求!),那么怎么办呢?

首先我自然是查看这个类中定义的方法,比如我看到了如下这个方法:

QQ截图20131220214047

于是我高兴得蹦了起来(当然不是真实的“我”,因为我知道这个东西的实现原理),原来可以像数组一样直接按索引访问,哇哈啊哈,那问题就简单了。

为了说明会导致的问题,假如这个人采用了如下这种方式去计算队列里各元素之和(当然扩展方法提供了Sum聚集函数,但为了说明问题我只是举一个例子):

            var cq = new ConcurrentQueue<int>();

            for (int i = 0; i < 500000; i++)
                cq.Enqueue(i);

            Int64 sum = 0;

            for (int i = 0; i < 500000; i++)
                sum += cq.ElementAt(i);

            Console.WriteLine(sum);

这会怎么样呢?按道理50万个元素遍历应该0.1秒都不需要,但是实际上运行的时候,很长时间程序都无响应——至少我等了十几秒都没看到出结果。

这是为什么呢?那么我们只有查看ElementAt这个扩展方法的定义:

public static TSource ElementAt<TSource>(this IEnumerable<TSource> source, int index);

可以看到ElementAt是IEnumerable<T>这个泛型接口的扩展方法,它接收一个IEnumerable<T>的实例对象以及索引作为参数——那么就意味着:每次访问ElementAt方法都会产生一个迭代器

那么我们那个代码遍历50万个元素,每访问一次ConcurrentQueue中的元素都会生成一个包含50万个元素的迭代器(内部实现其实是把队列中的元素复制到一个List中的),程序的运行时间可想而知。

不光是这个方法,定义在数组、List等集合类型的扩展方法大都是IEnumerable接口的扩展方法。那么LINQ在执行的时候,比如下面这个查询语句:

            var r = from c in cq
                    where c.Age > 20 && c.Name.Length > 0
                    orderby c.Name 
                    select c;

在编译后,实际上是生成的下面这种链式查询:

var r2 = cq.Where(c => c.Age > 20 && c.Name.Length > 0).OrderBy(c => c.Name);

按照由于都是IEnumerable的扩展方法,所以这个查询实际上会产生2个额外的迭代器,也就是说对象的引用会被赋值2次,更复杂的查询肯定需要更多的操作。此外,由于是迭代器,所以不会像数据库那样会有任何优化(比如索引),元素都是按顺序遍历的(每个predicate都会针对每个元素执行一次),所以效率肯定不高。

我个人认为Microsoft提供这种LINQ方式(包括扩展方法)在很大程度上减少了程序员的负担,使其很方便地可以对数据进行复杂的操作。但由于这种便利,很容易被“初学者”滥用(不光是“初学者”,不少很有经验的程序员都意识不到这一点),在数据量稍大的情况下差异逐渐显现出来。

我觉得Microsoft提供LINQ这种强大的机制是好的,但是应该强调它的实质以及使用时注意事项,给予开发人员更多地提示(比如ElementAt方法),并且对于类似于ConcurrentQueue、Hashset之类不要实现IEnumerable的接口(本来用了这些特殊数据结构的程序无论如何都不应该去遍历元素),让他们意识到可能会发生的问题。

这样,在论坛上就不会看到N多新手喷LINQ的效率太差的情况了。

 

4. 不支持内联方法

C#把C++的非虚方法都抄过来了这个为啥不抄过来呢?还是以我那个超大数据的ConcurrentQueue为例,假如我要对其中每一个元素进行操作,比如返回所有人的名字的大写并生成迭代器

var new_enumerator = cq.Select(c => c.Name.ToUpper());

Select扩展方法实际上接收的是一个委托:

public static IEnumerable<TResult> Select<TSource, TResult>(this IEnumerable<TSource> source, Func<TSource, TResult> selector);

那么对于我们这50万个元素的东东,这个委托就会被访问50万次,对于这种频繁调用方法的开销在这种情况下是非常大的。假使C#支持C++那种inline的方法就会显著改善这个问题。

但CLR生成代码的时候可能会产生优化生成内联的方法,但似乎有限制(比如方法不能超过32个字节等等)。无论如何不灵活也不透明,C#应该让程序员来选择哪些方法可以内联(况且实现的代价也不大我觉得)。

 

 

3条评论


  1. 1、对于面向对象来说,数组和原生类型都是该扔入垃圾堆的东西。
    3、对于一个工具,越用越熟,越用越好用,越用越以该工具的角度思考问题。

    Google Chrome 30.0.1599.101 Google Chrome 30.0.1599.101 Windows 7 x64 Edition Windows 7 x64 Edition
    回复

    1. 不能这么说吧。
      在一般情况下确实应该尽量使用安全的包装类比如List等。
      但数组还是有适用的时候,比如如果没有数组,.NET它自己就得使用不安全的上下文来实现List、ConcurrentQueue了。

      Internet Explorer 6.0 Internet Explorer 6.0 Windows XP Windows XP
      回复

发表评论

电子邮件地址不会被公开。