现在还存在多次扫描处理的问题，也就是说虽然代码结构性重构是成功的，但是性能问题还是没有根本解决。
在给出解决方案之前，需要对这个处理方式缕一缕：
处理方式1：每次遍历全路径找到待处理文件，文件然后批量进行处理。优点是处理起来比较简单，但是会重复扫描。
处理方式2：一次遍历所有文件，然后对每个文件进行注解检测。扫描全路径只有一次，然后要把每个文件与过滤器进行比较如果比较成功那就做，比较不成功就不做。
稍加分析就会发现，两种方式的比较次数是一样的，但是第二种方案遍历文件的次数就少到极限了，还能比1次更少么？？
这次的做法就有点复杂了（相对的，实际上也很简单）,做一个过滤器，里面放个Map存储过滤器：处理器。
对于每个一个文件，都对所有的过滤器进行校验，如果校验成功，就执行对应的处理器。
|
1
2
3
4
5
6
7
8
9
10
11
|
public
class
ComplexFileFilter
implements
FileObjectFilter {
Map<FileObjectFilter,FileObjectProcessor> filterProcessorMap;
public
boolean
accept(FileObject fileObject) {
for
(FileObjectFilter filter:filterProcessorMap.keySet()){
if
(filter.accept(fileObject)){
filterProcessorMap.get(filter).process(fileObject);
}
}
return
false
;
}
}
|
呵呵，性能的问题也提升完毕了。
至此，从几个看似重复的方法，我们通过层层分析，细致推理，终于找到了内部的复杂关系，通过重构，给程序员以便捷的开发与扩展，给使用者以高效的性能和一目了然的逻辑，皆大欢喜了。
总结：许多的时候，一些纠结，重复，无从动手，都是有其内在的复杂因素的，之所以剪不断理还乱，是因为没有抓住实质，但只要把它理顺了，其实各干干的，就简单了。
