依靠動態規劃編寫單詞提示功能 頂 原 薦

單詞提示功能

單詞提示在ide中特別常見，eclipse，ideal等等，包括atom等等文本編輯器中也有這樣的功能，基本就是你寫個單詞字母，他來提供你可能想輸入的單詞，例如寫個Str,就會提示String,StringBuilder等等。而且在你寫錯的時候，你要點擊提示，纔會告訴你是不是改成其他單詞相似的，提示的時候並不做這個功能。例如ssb,你可能是想寫StringBuilder的。一般是這種是不給提示的。本文就來做一個在你有手誤的情況下還能正常給提示的功能。還有就是不需要首字母提示，例如寫個Builder,也可以去匹配到StringBuilder的。

實現的關鍵點

根據上面的描述，其實可以發現這就是一個字符串匹配問題。每一個字符串都要和字典裏的做匹配，那執行效率是個問題。所以我們把重點放在一個單詞如何匹配以及併發操作上。

字符匹配方式

字符串匹配方式有很多，我們的前提是考慮允許出錯的，那麼精準匹配的方式就不那麼適合了。正則表達式起碼可以排除了。暴力枚舉的方式是可以的，只是想想就算了，都是n次方級別的，枚舉下來時間太多了，我們可以把這個問題轉化爲一個公共子序列問題，最後看看子序列長度佔匹配字符的長度，來算容錯率。不是很明白的匹配方式的請查看下面的文章。 動態規劃查找子序列問題

併發匹配

這個就需要藉助線程池來做了，並且可以獲取返回值。內容簡單可以直接上代碼。

        StringBuilder sb = new StringBuilder();
        List<Future<String>> result = new ArrayList<Future<String>>(dic.size());
        for (String dicString : dic) {
            result.add(pool.submit(new CharMatching(input, dicString)));
        }

        for (Future<String> future : result) {
            String data = future.get();
            if (data != null) {
                sb.append(data);
                sb.append(" ");
            }
        }


        return sb.toString();

匹配方式的優缺點

動態規劃找公共子序列速度不慢的，但是ide裏並不是靠他來做的，主要是lucene,ide的字典量特別大，都收入內存就不合適了。還主要是靠文件來做存儲。那麼動態規劃帶來了什麼好處呢，首先算法並不慢，m*n。在量大的情況下，比暴力破解好太多了。內存中都能獲取到值，那麼就可以考慮做到容錯了處理了。帶來了一定的靈活性。 代碼地址如下，有興趣的可以繼續改良。https://github.com/xpbob/Automatic-prompt