我写了一个通用函数,根据所传的参数来确定具体的处理步骤,但是虽着情况的复杂,所要考虑的问题也越来越多造成参数个数越来越多.
我一个方法参数的个数都达到7,8个.然后根据这7,8个参数的值来分辨不同的情况然后确定不同的处理方法.我觉得这样搞下去不是办法.大家有没有什么好主意指导一二.
[b]问题补充：[/b]
什么是表驱动的方式?初学者不是很懂,能详细介绍一下吗
其实楼上说得没错，如果能想办法做到单一职责那是最好不过，“通用函数”通常不是什么好的解决方案……
表驱动的概念就像把原本固定在代码里的条件给搬到数据里去。最简单的例子，如果我原本写了一个switch：
[code]switch (c) {
case 'a':
A();
break;
case 'b':
B();
break;
//...
}[/code]
那条件个数一多就麻烦了。如果换成表驱动形式，可以是：
[code]// 先在构造器或者之类的地方初始化表
// 假设ops是HashMap
ops.put('a', new MyStrategyA());
ops.put('b', new MyStrategyB());
//...
// 然后在用的时候，只要例如：
ops.get(c).doSomething();[/code]
其中MyStrategy是个接口，可以像是：
[code]public interface MyStrategy {
void doSomething(); // 或者适合你的使用场景的返回类型
}[/code]
而MyStrategyA、MyStrategyB那些就是该接口的实现类。
这样做的话，每个实现MyStrategy接口的类都只负责一种情况，而所有情况被归集到一个表里处理，那么“通用函数”的实现也会简单些——只要查表就行。
如果有兴趣的话，可以读一下《代码大全》第二版的第十八章，里面对表驱动方法有比较详细的介绍
楼主说的“通用函数”也就是涉及很多硬编码的判断逻辑的咯？硬编码开始混乱的话，改成表驱动的方式试试？把“具体步骤”用strategy封装起来，然后把strategy对象根据条件放入一个表里，然后你的“通用参数”就变成查表操作了。
不要用通用方法了
单一职责原则
一个方法只完成一件事情
RednaxelaFX说的其实是控制反转的典型
就是设计模式里面的经典例子，好比ssh里面那一堆配置文件（fx所说的表）
实现依赖抽象，抽象不依赖实现
比如策略模式＝
执行什么方法不靠你的参数判断，而是在子类构造的时候就决定了
不同的逻辑下，创建不同的对象（实现类），抽象去执行doSomething()的时候，自然是正确的逻辑
补充个不恰当的例子，用数据库表形象一点
select classname from class where paramA = ? and paramB = ? ...
context.getBean(classname).doingSomeThing();
或者
select methondName from class where paramA = ? and paramB = ?
Method m = new Method(this.getClass().getMethod(method,null));
m.invoke(obj, args);