我发现有时候程序员不是不会写代码,而是老是在纠结这个代码怎么写才比较好,好扩展,又漂亮,一份代码控制多个点.毕竟程序员都是惜字如金,少打一行是一行,简洁一个是一个.
虽然累积了越来越多的经验也不用纠结越来越多了,但今天又回到了一个老问题上:方法的参数表设计成一个个好,还是一个数组通过键名来表达好?
我想大家都清楚这个问题,总会接触到这种的,参数表本来定了ABCDE参数,后来需求变,BC删除,增加F,整个项目找代码改呀改,还害怕改漏了哪里,导致旧代码传少传多参数而运行出错
我发现JS方面则越来越流行用键值对(算它是关联数组吧)来做传参,特别是一些UI插件初始化时的指定选项,当然由于那些参数太多,换成一个一个参数传的话很难记住哪个参数位是哪个,如果用键值对的话只需要记住必要控制的哪些键和可选择控制的属性键就可以,一定程度上来说这样设计是为了可选参数,而PHP方面偶尔会见到这样的设计,但其实这样做的话貌似方法调用就会麻烦点,并且表达不直接
addUserIcon(用户ID, 金币数量);
总好比addUserIcon(array('uid' => 用户ID, 'qty' => 金币数量))
大家说说吧,上面只是一个简单例子,复杂起来又感觉数组好办点,这样一东一西的就变得没有统一了,开发过程中又会纠结代码不统一的问题了,一个做法这样一个做法那样.当然受气的只是自己,老板只要你实现.
对于 C++ 你的问题是通过函数的重载实现的
但是 php 并不支持重载（因为web开发不需要弄的那么复杂），但 php 提供了参数的缺省来变通
因此可以通过检查实际传入的个数来决定流程的走向
但你把参数由 ABCDE 改为 ADEF 是不可取的
因为原来按 ABCDE 调用的部分都将发上歧义
对于 C++ 你的问题是通过函数的重载实现的
但是 php 并不支持重载（因为web开发不需要弄的那么复杂），但 php 提供了参数的缺省来变通
因此可以通过检查实际传入的个数来决定流程的走向
但你把参数由 ABCDE 改为 ADEF 是不可取的
因为原来按 ABCDE 调用的部分都将发上歧义
换个说法就是比如本来要用户的年龄,性别,地区,XX,YY...,但某天项目需求一变又说不要性别和地区了,然后加个签名吧...
假设方法就是setUserInfo
那么设置用户信息这个调用点可能会在用户资料修改,后台对前台用户资料的修改,或者用户通过其它接口操作修改部分信息中调用,现在如果不改这个方法的参数表,请问我该怎么办?开多个新方法,setUserInfo2?但是其它调用点还是要修改调用的参数名和参数表
一般不去涉及数据集合的细节
比如用户信息就是 {用户id,年龄,性别,地区,等等} 的集合，而用户id就可唯一识别该用户
又比如 {年龄,性别,地区} 是一个过滤集合，而 {年龄,签名} 是另一个过滤集合
所以你只需要传递需要的过滤集合编号就使程序变得通用了
而维护这些集合的技术就是：数据字典
