目錄
實踐中的重構01_小方法的細調
實踐中的重構02_**的視覺效果
實踐中的重構03_批處理方法預設約定
實踐中的重構04_了解每一行** 裝箱的布林值
實踐中的重構05_簡潔的**
[b]實踐中的重構01_小方法的細調[/b]
重構的概念已經為廣大的程式設計師所熟悉。但是還是有很多細節可以注意。
public static string gethiddenemail(string email, int prefix, int suffix)
int length = email.length();
if (length < default_total)
// @所在位置
int splitpos = stringutil.lastindexof(email, '@');
// @前的字元段
string preemail = stringutil.substring(email, 0, splitpos);
if (stringutil.isblank(preemail))
// @後的字元段，包含@
string latemail = stringutil.substring(email, splitpos, length);
if (stringutil.isblank(latemail))
if (preemail.length() > 17)
preemail = stringutil.abbreviate(preemail, prefix);
if (latemail.length() > 13)
latemail = stringutil.abbreviate(latemail, suffix);
return preemail.concat(latemail);
}
以上的code在我看來，有以下幾個缺點。
1 方法名和實際的方法體不匹配。
2 魔數
3 if (stringutil.isblank(latemail)) 永遠返回false，因為當程式執行到這裡，latemail至少包括乙個字元@。
4 方法中的**的內聚性不夠。主要是對preemail和latemail的處理分開了。
5 拼寫錯誤，應該為lastemail而誤拼為latemail
清洗**後如下
private static string getabbreviatedemail(string email, int prefix, int suffix)
if (email.length() <= default_total)
// @所在位置
int splitpos = stringutil.lastindexof(email, '@');
if (splitpos == -1 || splitpos == 0)
// @前的字元段
string preemail = stringutil.substring(email, 0, splitpos);
if (preemail.length() > default_prefix_length)
// @後的字元段，包含@
string lastemail = stringutil.substring(email, splitpos, email.length());
if (lastemail.length() > default_suffix_length)
return preemail+lastemail;
}
其實我個人最喜歡的風格是簡單的方法的guard condition不用大括號{}，這樣**變為
private static string getabbreviatedemail(string email, int prefix, int suffix)
// @後的字元段，包含@
string lastemail = stringutil.substring(email, splitpos, email.length());
if (lastemail.length() > default_suffix_length)
return preemail+lastemail;
}
[b]實踐中的重構02_**的視覺效果[/b]
相信程式設計師都會承認讀**的時間比寫**的時間長。那麼有沒有寫**的時候有沒有什麼可以幫助其他程式設計師甚至自己快速讀程式的手段呢。
試看一例，當然這裡給的日誌很簡單，實際中對於重要操作，日誌是要打很多東西的。
trycatch(exception e)
log.info("msg");
從視覺上看，不是很清晰。
trycatch(exception e)
ok，不用思考了，一眼瞟過去，就知道乙個log是成功日誌，乙個是失敗日誌。
[b]實踐中的重構03_批處理方法預設約定[/b]
最近看**的時候，發現了乙個奇怪的現象。關於呼叫批處理介面的問題。
如呼叫乙個查詢使用者資訊的介面為
userinfo getuserinfo(string id)
則對應的批處理介面為
listgetuserinfobyids(listids)
很多地方對該返回值進行了校驗，即用for迴圈比對返回的userinfo進行比對，擔心返回的列表的長度和傳入引數的長度不同，擔心返回的列表的順序和傳入引數的順序不同。
我覺得這樣大可不必。呼叫批處理介面，應該是符合common sense的。
即可以返回乙個null,可以返回乙個empty list,其他情況都是返回乙個大小和傳入引數個數相等且順序一致的列表。
如果有特殊情況，應該在方法的介面定義中特別宣告，這樣呼叫方的code會比較清晰好讀，也符合一般人的直覺。讓呼叫方做校驗，這樣的想法如果沒有很強大的理由，還是不要的好，因為遵守預設約定，有可能服務方的**會稍微複雜一點，但是考慮到多處呼叫方的**的簡潔和易讀，這點代價完全是值得的。
[b]實踐中的重構04_了解每一行** 裝箱的布林值[/b]
最近看到**中有這樣的code.
boolean isneedproxy = (boolean)threadlocalmap.get(ip);
return ( isneedproxy == boolean.true ) ? true : false;
我的猜想是程式設計的人為了防止isneedproxy為null，所以有了這段**。
這裡有個問題。
如果儲存的值是new出來的boolean，那麼這裡的邏輯就是錯的。
@test
public void testboolean()
這樣寫就好了
return isneedproxy==null?false:isneedproxy;[b]實踐中的重構05_簡潔的**[/b]
if (a|| b|| c)
return false;
可以改為
return a|| b|| c;實踐中的重構03 批處理方法預設約定
最近看 的時候，發現了乙個奇怪的現象。關於呼叫批處理介面的問題。如呼叫乙個查詢使用者資訊的介面為 userinfo getuserinfo string id 則對應的批處理介面為 listgetuserinfobyids listids 很多地方對該返回值進行了校驗，即用for迴圈比對返回的use...
java 實踐中的問題
1 int等值與string之間的轉換 用string.valueof 方法將boolean char int double float long char等轉化為字串 用int i integer.parseint string s,int radix 或int i integer.parsein...
實踐中的各種問題
1.今天遇到了url的編碼問題 將字串以 url 編碼。例如空格就會變成加號，當我們傳入的引數中含有空格時，在伺服器端接收到的是空格轉成了 符的字串，導致失配，妹妹的！這麼搞也不事先說一聲，問題找的好辛苦，這時我們將用到乙個函式rawurlencode 他可以將空格等字元正確的轉義，變成 20等 這...