方法参数超级多,看着有些混乱怎么处理好呢?

liushaog 发布于 2014/07/02 16:19
阅读 383
收藏 0

方法有N多参数,每个参数都是可选参数可以为null。


queryPaging(String uid, int currPage, Integer view, Gender gender, String circleId, String key, String paixu, String order, String[] filterIds);



加载中
1
clt
clt
多种方式:
1. 封装成对象,不好处是太隐蔽了。
2. 保保留必要的参数,其它通过 Map 或 Object 传进来。
3. 参考 StringBuffer 的调用形式,每调用一次传递一个或多个参数,返回自身,继续  "." 添加其它参数, 比如 .uid(xx).page(currPage).order(xx).key(xxxx)
xmut
xmut
封装成对象怎么算是隐蔽呢? 那VO对象干嘛用……
liushaog
liushaog
map 或obj 太隐蔽了,链式和封装可用性感觉比较好
1
憨厚的瓜
憨厚的瓜
我是觉得链式最好,内部结构清晰,不用写作一坨,写的人清晰,用的人也清晰,读的人也清晰
0
王爵nice
王爵nice
用Map<String, Object>不可以吗,参数名称作为key,当参数为null的时候不进行put。
liushaog
liushaog
这样有个弊端,改动key后关联的不容易发现
0
蓝色幽默
蓝色幽默
封装成参数对象
liushaog
liushaog
封装好的 参数对象放到哪?在当前类下建个属性类?
0
18号
18号
封装吧
liushaog
liushaog
封装的对象放哪里好?
0
sxgkwei
sxgkwei

对于我这个用的人来说吧,我就觉得你这样挨着写,用起来最舒服,map什么的,我怎么知道KEY是什么?一次弄一个参数进去不停地返回本身把,我真要设置多个参数进去时,麻烦。

还是你这样公开出来,方法上面把注释写清楚给我,就行了,你简单,我也方便。

liushaog
liushaog
额,也是
0
Timco
Timco
我的做法是先收集相关的参数构成一个条件类,比如QueryCon,它可以使用builder设计模式来填充参数。然后将该类传入你这个方法 :-)
0
我心-永恒
我心-永恒
封装,用集合
liushaog
liushaog
集合太隐蔽了
0
中山野鬼
中山野鬼
哈,禽兽不如的乱喷一句,还是可变参好。。。
中山野鬼
中山野鬼
回复 @拉风的道长 : 自行定义,发布说明。模块内部对参数存储空间自然要有审核判定,不符合的,弹掉。哈。无非很多事情要自己写代码,不过逻辑更明确,可操作性更强,你想咋样就咋样,何苦纠结某个工具为啥不给力。哈
拉风的道长
拉风的道长
回复 @中山野鬼 : 就当做是C,也不太好弄吧,参数的类型,意义都不一样的。
中山野鬼
中山野鬼
回复 @拉风的道长 : 我说的是c。哈。
拉风的道长
拉风的道长
怎么个可变 法?
0
不算帅
不算帅
你把所有的逻辑揉在一起,自然需要很多参数。分成多个方法,每个方法专注于做一件事,这样日后也好维护
liushaog
liushaog
粒度细一些入口放在action层?逻辑处理不能复用啊。
返回顶部
顶部