悠然亂彈：從幾個方法的重構講開去--性能大優化

上一篇講到通過上面兩篇的優化與重構，總體來講，前面提到的問題，除了性能問題以外，其它問題都已經順利的解決了。

如今還存在屢次掃描處理的問題，也就是說雖然代碼結構性重構是成功的，可是性能問題仍是沒有根本解決。

在給出解決方案以前，須要對這個處理方式縷一縷：

處理方式1：每次遍歷全路徑找到待處理文件，文件而後批量進行處理。優勢是處理起來比較簡單，可是會重複掃描。

處理方式2：一次遍歷全部文件，而後對每一個文件進行註解檢測。掃描全路徑只有一次，而後要把每一個文件與過濾器進行比較若是比較成功那就作，比較不成功就不作。

稍加分析就會發現，兩種方式的比較次數是同樣的，可是第二種方案遍歷文件的次數就少到極限了，還能比1次更少麼？？

此次的作法就有點複雜了（相對的，實際上也很簡單）,作一個過濾器，裏面放個Map存儲過濾器：處理器。

對於每一個一個文件，都對全部的過濾器進行校驗，若是校驗成功，就執行對應的處理器。

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;
    }
}

呵呵，性能的問題也提高完畢了。

至此，從幾個看似重複的方法，咱們經過層層分析，細緻推理，終於找到了內部的複雜關係，經過重構，給程序員以便捷的開發與擴展，給使用者以高效的性能和一目瞭然的邏輯，皆大歡喜了。

總結：許多的時候，一些糾結，重複，無從動手，都是有其內在的複雜因素的，之因此剪不斷理還亂，是由於沒有抓住實質，但只要把它理順了，其實各乾乾的，就簡單了。