也说责任链模式应用

简单的问题，复杂化了。将代码细化一下。

区分场景，区别对待！

if(c1&&c2&&c3&&c4&&c5&&c6...)
  doBusiness();

Or

if(SomeCondition())
  doBusiness();

我对LZ设计有几个问题。
1.责任链模式（我没用过，纯属猜测）的精华应该是每个处理器都有权做自己的处理，你只需要把状态（对象）传递过去即可。
而LZ的每个处理器都有权决定下一个处理器是否进行处理？

if(flag && this.getNextHandler() != null) {  
            return this.getNextHandler().doRequest();  
} 

2.原先只有doBusiness()一个业务逻辑，LZ将业务逻辑分散给了各个处理器？

3.每个处理器不依赖原先的对象?

  个人感觉责任链应该是包含这样的业务逻辑：虽然都对某个对象做处理（也就是说，正常设计这些逻辑都应该是本对象的方法），但是，这些新逻辑又跟对象提供的核心业务逻辑不是一类型。比如日志、分析等等，一个提供业务运算的对象似乎不太应该提供负责存储、日志、分发等业务逻辑。当然，如果只有一两项，作为对象的方法没有关系，实际上，很多对象提供了打印调试信息、记录日志的方法，也没什么关系（但对广泛应用的对象不应该提供这些额外逻辑，谁知道我想以怎样的方式记录一个对象的信息？Log1()?Log2()?Log3()?）。但当额外的逻辑膨胀时，并且可以被分类时，责任链模式就成了一种选择。就像Unix中的各种Filter和Pipe(虽然他们是不同进程),你也可以把责任逻辑分布在各个系统中，那也就成了分布式处理。

Command模式，在楼主的例子中没有用武之地。

command模式，是为了将动作包装成一个对象来传递，可以做到撤销动作。

但是我通常是是用command模式来实现java 回调（callback）,将部分业务实现延迟到调用处来实现，如下面的代码：

public static void main(String[] args) {
        KissGirl kissGirl = new KissGirl().doKissing(
                new KissCommand() {
                    @Override
                    public void kissGirlLips(KissCommandContext kissCommandContext) {
                        System.out.println("kiss girl start,the girl is :" + kissCommandContext.getGirlName());
                    }
                });
    }

command命令模式的这种应用，和楼主的需求没有任何关系吧？

n多并行if-elseif，使用策略模式；
n多嵌套if-elseif，可以考虑职责链模式；
少量if-elseif，直接if-elseif即可，为了模式而模式，不可取。

用不用模式有一个非常清晰的判断标准：

【应该尽量使用设计模式】：软件系统架构设计者。
架构师在设计软件架构时，要做到功能模块尽量通用、易扩展，如：设计自己的MVC框架、设计自己的安全认证框架、设计自己的持久层框架等；

【不使用设计模式】：流水线程序员。
流水线程序员每天做得无非是：
1、Swing流水线程序员：画界面、填充按钮事件方法的空白处；
2、web流水线程序员：复制个action过来、复制个service过来，在service的某个方法里使用通用dao对象调用一下sql 或者HQL 或者 塞个对象到dao中；

所以流水线程序员多数情况下，根本就不需要用什么设计模式，即时让他们用，他们也不会用（我说的是我们自己的公司，各位看客不要紧张）。

就我自己而言，使用最多的模式是：
命令模式、职责链模式、代理模式、模板方法模式、builder模式和简单工厂模式；
偶尔用一下适配器模式，但是适配器实现的被适配接口越多，它看起来越不伦不类，所以我尽量少用他。

回调不是这个意思。

回调是什么意思？请教？