最近写了一个分表查询的lib，封装了一些数据结构，可以简化对于分表查询的实现。这个问题主要体现在，对分表进行查询时，原有的单表查询需要进行修改，或者需要在内存中进行处理。修改单表的sql可能导致性能问题，原有的优化可能失效。内存处理则需要一些技巧，搞不好会把太多内容加载到内存中，导致内存被耗光。

我的lib主要使用iterator的模式来解决数据库的读取的问题，每次只读取1000条，放在内存中，当iterator的next移动到缓冲区的尾部时，再次读取1000条，如此可以保证获得所有的数据。当然我们也可以采用双buffer的方式，一个用于提前读取，一个用于输出。不过现在还没这么做。

虽然command模式不是lib的重点，但是这个模式却教会了我一些东西。因为最开始的时候，我并没有想到它。开始，我想的是查询分成几类：

1. 查询结果做union all；

2.查询结果做order by

3. 查询结果做group by

4. 查询结果去重

我发现每个查询都有这样一些参数，一组表名，一个数据库查询的封装，如果需要排序的话，得要一个comparator，如果需要合并的话，得要一个MapReduce。

最初的实现是：

class QueryService{         
  Iterator<T> query1(a,b);          
  Iterator<T> query2(a,b,c);          
  Iterator<T> query3(a,b,d);          
}

后来发现参数太多，初始化比较麻烦，于是改成：

X{         
a,b          
}          
X1 extends X{          
c          
}          
X2 extends X{          
d          
}          
class QueryService{          
  Iterator<T> query1(X);          
  Iterator<T> query2(X1);          
  Iterator<T> query3(X2);          
}

接着发现，这个设计缺乏扩展性，如果将来需要添加新的查询类型，或者想要换一种实现方式，就得修改整个query service。而且X X1 X2只有属性，太浪费了，没有实现封装的目的。更重要的，各个查询其实如果设置好上下文，调用方法都一样，返回值一样。这不就是command的用法吗。

Cmd{         
Iterator run();          
}          
X implements Cmd{          
a,b          
}          
X1 extends X{          
c          
}          
X2 extends X{          
d          
}          
class QueryService{          
  Iterator<T> query(Cmd);          
}

这样上面的难题就迎刃而解了。为什么我一开始没想到呢。我想到了不同的种类的查询，过分关注他们的不同点，忽略了查询的共同点。所以以后工作中，一定要先抽取共性，再寻求个性。共性有利于整体考虑，个性有利于细化架构，发现新的机会。