你的位置:首页 > ASP.net教程

[ASP.net教程]【C#进阶系列】08 关于参数的故事


可选参数和命名参数

不多说,上代码,自然懂

  class Program  {    static void Main(string[] args)    {      var troy = new Troy();      troy.HelloWorld(1);//此时b和c都为0      troy.HelloWorld(1,2);//此时b为2,c为0,以上两个为可选参数的玩法      troy.HelloWorld(a: 1, b: 2);//命名参数玩法      troy.HelloWorld(b: 2, a: 1);//即使顺序打乱,效果也是一样    }  }  public class Troy {    public void HelloWorld(int a, int b = 0,int c=default(int)) {//这里b和c参数就是可选参数      //注意default(int)这种玩法,表示int的默认值。      //我是第一次知道这种用法,然而非常推崇这样的玩法,因为可以有效减少你代码中的魔法数字。也许你认为0这种不算魔法数字,然而我认为能让代码更简单易懂一点点也是非常有必要的。      //就算不用魔法数字,那么default(DateTime)去判断DateTime值是否为默认值,是不是比new Datetime()更好一点呢?    }  }

默认参数实际上在C#编译器编译过后就向该参数应用特性OptionalAttribute和DefaultParameterValueAttribute。并不是CLR支持的,而是C#特有的。

这两个东西看上去都那么美好,然而美好的东西并不一定真的好。

推荐用命令参数,然而不要为了调换顺序而调换顺序。实际上对VS这么强大的工具而言,命名参数只有在参数非常多的时候才有用。

如果你的参数太多,那么其实更应该考虑缩小一下参数的数量。可以考虑提取一个参数对象,传值的时候传这个参数对象就好了。

虽然我非常喜欢用默认参数,实际上它也确实很好用,特别对于重载而言,你有的时候根本没必要去写两个函数。

然而这实际上也是个坑点。

如果你和我一样喜欢用,你团队的人也喜欢用。那么最后你会发现,这个东西总是会让函数内部充满了各种各样的分支,你的参数列表也会越来越长。o(︶︿︶)o 唉

如果你不懂那么可以看一下我写的一个代码维护小故事,请想象一下你在维护的是一个业务复杂的大型系统,那么接下来的节奏会经常发生。

     //最开始Troy写了一个打招呼的函数    public void 打招呼()    {      Console.WriteLine("你好");      //下面还有一系列握手,微笑之类的操作    }    //后来老板说国际化,也要能英文打招呼.你选择了默认参数,并且为了保证以前的代码顺利运行,默认为false    public void 打招呼(bool IsEnglish=false)    {      if (IsEnglish)      {        Console.WriteLine("Hello");      }      else {        Console.WriteLine("你好");      }      //下面还有一系列握手,微笑之类的操作    }    //到了上面那一步也是OK的,然而过了两天,老板跟大牛说有的老外有可能不握手,他选择拥抱。于是大牛改代码:    public void 打招呼(bool IsEnglish = false, bool 是否选择拥抱 = false)    {      if (IsEnglish)      {        Console.WriteLine("Hello");      }      else {        Console.WriteLine("你好");      }      if (是否选择拥抱)      {        Console.WriteLine("拥抱");      }      else {        Console.WriteLine("握手");      }      //下面还有一系列微笑之类的操作    }

当然即使到现在,以上的代码看起来也仅仅只是分支增多而已,然而请你设身处地去想一下,如果这个系统的业务很复杂,如果后面还有需求,如果不仅仅只是一个Console.WriteLine这么简单的操作。

等到第四次去修改的时候,新来的项目组成员小菜已经没得选了。首先他不熟悉业务,不敢乱改,他甚至可能熟悉也懒得改,因为改起来已经很麻烦了(不要太相信你的队友,我就是这样的懒人(☆_☆)),那么这个时候他只能默默选择再加一个默认参数。

有第四个,肯定就会有第五个,每次想要重构感觉难度越来越大,心里越来越虚,只好随大流去加默认参数,经过大家一起努力,这段代码已经差不多10个分支了,大家都不敢改了。

如果从一开始不选择加默认参数,而是多写一个重载函数,将公共部分提炼出来,那么你觉得还会有这样的问题吗?

然而并没有什么鸟用,即使是我了解的这么清楚,我经常会觉得我在加第三次默认参数完全没有任何问题,偷点懒赶紧下班啦,代码依然能看,等我下次回来改的时候,我发现默认参数已经变成5个了。o(︶︿︶)o 唉

out和ref的故事

CLR不区分out和ref,生成的IL代码一模一样,只是元数据会有个bit值加以区分。

out表示传递的是引用类型,然而他并不需要调用的时候这个参数就初始化完毕,且要求函数执行完毕的时候out参数必须被写入过。

ref要求调用的时候这个参数就初始化完毕,且不要求函数执行完毕的时候ref参数必须被写入过。

实际上在C里面这个东西就是指针,我们这里来讲这东西传递的就是值的地址。

如果有大的值类型的传参,比如一个大型struct。

那么用这种方法传参只会传一个地址值,而不是把每个struct里面的值都压到栈中。

另外不要因为ref比out好用就不用out,out可以明确你这个参数一定会传值出来,读代码更容易。

pramas传递可变数量的参数

这个网上一大堆,我用得最多的就是String.Format方法,可以参考这个来了解。

不过要注意这个会有性能损失,因为传递的pramas一维数组,实际上是分配在堆空间中的,初始化啊,垃圾回收啊,都会有影响。

参数和返回类型的设计规范

声明方法的参数类型时,应该按照最低接口类型,更强的接口类型,基类,派生类从高到低的优先级来声明类型。

因为用接口或者基类会让你的方法更加灵活,可以选择的余地更大。

而返回类型正好相反,防止受限于特定类型。

以上是作者讲的,有道理,但是具体情况具体分析,难道要我们都去声明object,那一切都OK了?

作者的意思显然不是如此。我认为你可以在第一次的时候去选择最适合的强类型参数,但是下一次有一个类似的函数时,而两个参数间有一个共同的接口或者基类,那么是否可以考虑一下将参数的类型弱化呢?这样明显可以让代码更灵活。

但是不要因此直接就用个object之类的,不要过度设计,永远用目前最满足需求的那个,不要把未来全部考虑完全,因为你根本预测不到未来。