成对的Request和Response

     前几天，不知道怎么搞的突然想起了刚刚开始工作时的一个老问题（当时还在做J2EE）：“为啥Request和Response在参数里面成对出现并且经常只用一个？”。这个问题表面上似乎不太像一个问题，随便抓一个人做了几年J2ee的会抛给你一句：“框架是这么写的嘛，管他的用就是了”。换几年前的我估计也得这么说，心里面甚至还会想“管我屁事！ 写成怎么样不影响我干活儿就行！”。但是一个码农总是会成长的，他的反应也会变成：“这到底是不是一个API的设计模式？”
    经过几天的研究，我觉得可以把这个总结成一种比较通用的写法来处理不断增长的输入参数和单增长的返回值，并且赋予了干预中间处理的能力。我不想叫这个是一个设计模式，因为这毕竟不是常用1/23。我首先简化一下这种写法：

 public interface ServletRelated {

    public void doData(Request request, Response response);
    
    public final class Request {
        // only getters public, rest hidden only for friend code
        Request() {
        }
    }
    
    public final class Response {
        // only setters public, rest available only for friend code
        private final Map<String,String> result;
        /** Allow access only to friend code */
        Response(Map<String,String> result) {
            this.result = result;
        }
        
        public void add(String s) {
            result.put(s, s);
        }
        
        public void addAll(List<String> all) {
            for (String s : all) {
                add(s);
            }
        }

        /** @since 2.0 */
        public void add(String s, String description) {
            result.put(s, description);
        }
    }
}

    这种写法只需要向request里面添加类似Getter的方法就可以给doData带来更多的参数。另外final意味他是一个标准的客户端API。同理用Setter添加Response相当于给doData添加了返回值，另外注意我的注释（适当控制读写权限）。
    用这种写法可以让doData以Chain的方式处理中间结果，让输入和返回结果的处理方式分离（校验，延时甚至取消）。

    我不会再想这样的问题了。