Http解析中的OCP设计模式问题

0 0

Http解析中的OCP设计模式问题5

问题描述：
目前现在实际场景是需要自定义Hadoop的InputFormat，需要对包含大量HTTP内容（包括HTTP包头和内容，用\r\n\r\n分隔每段HTTP）文件进行解析，其中的HTTP METHOD有GET、POST、PUT等等，只需要提取GET、POST、PUT三种方法的内容。格式如下：

引用

GET http://localhost:8080/tienda1/publico/anadir.jsp?id=2&nombre=Jam%F3n+Ib%E9rico&precio=85&cantidad=%27%3B+DROP+TABLE+usuarios%3B+SELECT+*+FROM+datos+WHERE+nombre+LIKE+%27%25&B1=A%F1adir+al+carrito HTTP/1.1
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.5; Linux) KHTML/3.5.8 (like Gecko)
Pragma: no-cache
Cache-control: no-cache
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Encoding: x-gzip, x-deflate, gzip, deflate
Accept-Charset: utf-8, utf-8;q=0.5, *;q=0.5
Accept-Language: en
Host: localhost:8080
Cookie: JSESSIONID=B92A8B48B9008CD29F622A994E0F650D
Connection: close

POST http://localhost:8080/tienda1/publico/anadir.jsp HTTP/1.1
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.5; Linux) KHTML/3.5.8 (like Gecko)
Pragma: no-cache
Cache-control: no-cache
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Encoding: x-gzip, x-deflate, gzip, deflate
Accept-Charset: utf-8, utf-8;q=0.5, *;q=0.5
Accept-Language: en
Host: localhost:8080
Cookie: JSESSIONID=AE29AEEBDE479D5E1A18B4108C8E3CE0
Content-Type: application/x-www-form-urlencoded
Connection: close
Content-Length: 146

id=2&nombre=Jam%F3n+Ib%E9rico&precio=85&cantidad=%27%3B+DROP+TABLE+usuarios%3B+SELECT+*+FROM+datos+WHERE+nombre+LIKE+%27%25&B1=A%F1adir+al+carrito

PUT http://localhost:8080/tienda1/publico/registro.jsp HTTP/1.1
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.5; Linux) KHTML/3.5.8 (like Gecko)
Pragma: no-cache
Cache-control: no-cache
Accept:text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Encoding: x-gzip, x-deflate, gzip, deflate
Accept-Charset: utf-8, utf-8;q=0.5, *;q=0.5
Accept-Language: en
Host: localhost:9090
Cookie: JSESSIONID=2266B1AC9E10E859DA43028606239875
Content-Type: application/x-www-form-urlencoded
Connection: close
Content-Length: 252

modo=registro&login=armand&password=prusiato&nombre=Samia&apellidos=Catalayud+Mirabet&email=balademas.mareuil6%40enlanzarote.com.vc&dni=28178710F&direccion=C%2F+Cala%2C+9%2C+&ciudad=Mutxamel&cp=25332&provincia=Zaragoza&ntc=8608089924764976&B1=Registrar

如果不考虑OCP原则则直接一个类或者函数，里面用Scanner的hasNext()方法判断开始的Token是“GET”还是“POST”还是“PUT”，然后分别调用scanner根据每种情况（包括不是需要的三种方法的情况）分别去读取解析或者是跳过该行。

然而上述的这种方法，一来扩展性不好，可重用性为零。每个if语句里面可能包含大量代码，即使写到一个函数里面，扩展起来每次都得大量增加或者修改代码，耦合性过高。

于是考虑OCP原则（开放封闭原则）和SRP原则（单一职责原则），设计一个HTTPLoader的接口
public interface HttpLoader {

public String loadRequest() throws IOException;

public boolean tryLoad();
}

然后设计了一个AbstractHttpFileLoader的抽象类

public abstract class AbstractHttpFileLoader implements HttpLoader{

public InputStream in;
private Scanner mScanner;
private Pattern Delim;

public AbstractHttpFileLoader(InputStream in){
this.in = in;
mScanner = new Scanner(in);
}

public String next(){
return mScanner.next();
}
public boolean hasNext(){
return mScanner.hasNext();

}
protected boolean hasNext(String pattern){
return mScanner.hasNext(pattern);
}

public void setDelim(Pattern p){
Delim = p;
mScanner.useDelimiter(Delim);
}

public void reset(){
mScanner.reset();
}


public void setScanner(Scanner scanner){
mScanner = scanner;
}


}

然后分别设计各个方法的处理类，HttpGetLoader、HttpPostLoader、HttpPutLoader，继承AbstractHttpFileLoader并实现HttpLoader接口。

看起来好像比较可行，但是Scanner扫描器读取的时候是将内容缓存到自身的一个buf变量中的，然后利用正则表达式去匹配。
因此，如果实例化HttpGetLoader后，tryLoad之后其实就已经读入一部分数据到buf，这样对应的inputstream的位置已经发生了变化。要使用HttpPostLoader去tryLoad的时候依然是还没被之前的Loader载入到buf前的位置开始的数据，那么如果InputStream支持mark和reset，那么可以通过在开始所有的tryLoad之前mark，然后tryload里面先reset然后才真正开始调用scanner.hasNext方法探测。

while(end - pos >0){
     mark()
     if(getLoader.tryLoad()){ getloader.loadRequest()}
     else if(postLoader.tryLoad()){postLoader.loadRequest()}
     else if(putLoader.tryLoad()){putLoader.loadRequest()}
     else{
        LOG.warn("Unsupported method type");
   }
}

public boolean tryLoad(){
      in.reset()
      mScanner.hasNext("GET") //以GET为例
}

但是问题是现在实际场景是需要自定义Hadoop的InputFormat，然后FSDataInputStream并不支持mark和reset，所以，能够想到的解决办法是给每个具体的HttpLoader例如HttpGetLoader增加setScanner和getScanner，然后每次判断一种情况后，getScanner，然后通过setScanner设置给下一个要判断的HttpLoader

while(end - pos>0){
     if(getloader.tryLoad()){ getloader.loadReqeust();continue;}
     scanner = getloader.getScanner();
     postloader.setScanner(scanner);

     if(postloader.tryLoad()){postloader.loadRequest();continue;}
     scanner = getloader.getScanner();
     putloader.setScanner(scanner);

     if(putloader.tryLoad()){putloader.loadRequest(); continue;}
     
     //其他情况
     LOG.warn("not supported");
}

感觉这样不是很好，不知道大家对于这个问题有什么新的设计思路，或者更加好的办法？？
集思广益 ^ _ ^