C#进阶系列08 关于参数的故事
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了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之类的,不要过度设计,永远用目前最满足需求的那个,不要把未来全部考虑完全,因为你根本预测不到未来。
以上是关于C#进阶系列08 关于参数的故事的主要内容,如果未能解决你的问题,请参考以下文章