說明：標題所說的“類”，並不一定是指面向對象的類，而是泛指有著特定作用的代碼文件）
我寫代碼有個習慣，在一個工程建立之初，首先會建一個“工具代碼”目錄，在這個目錄裡會放入多種工具“類”，比如提供文件操作的，字符串轉換的，dump文件輸出windows），注冊表操作windows），計時器服務......等等。別小看這些工具類或方法，舉個簡單的例子，就拿ANSI和UNICODE字符的轉換來說，繞暈了不少人吧。文件操作，很多工程都會遇見吧，何不把其封裝成一個工具“類”，隨時加入各個工程進行使用，多的就不舉例了，總之可以把我們認為能提供某種功能的代碼實現都封裝成工具類供其他工程調用，你想想看，這像不像一把瑞士軍刀，開始也許只有刀子和起子，慢慢的變成一把集有各種工具的超級軍刀，怎麼樣，是不是用起來很爽。
但是，請注意，要是你用一把劣質的軍刀，割東西刀刃壞了，剪東西剪不動，......你肯定會發出“坑爹”的抱怨。寫工具類也是如此，這些工具類一定要是高質量的，穩定的，健壯的，最好還是跨平台的。
下面我來談談我寫工具類的一些經驗：
經驗1：不要重復造輪子，找別人寫好的。注意了，不是說那些從網上隨便搜來的，當然也不排除有高質量的。我呢，喜歡在著名的開源代碼裡或者有些洩露的著名商業代碼中搜索含有util關鍵字的代碼文件，很壯觀，一堆堆的，下面就是自己對這些工具類進行取捨了，反正我還是比較相信高質量的開源代碼和商業軟件的，一般取之就用，目前還未發生過不良反應。
經驗2：能跨平台的的盡量跨平台，畢竟我們現在都比較重視跨平台開發了，我呢，多喜歡用STL，boost，或者posix接口實現。至於依賴於系統API的，加上系統標識的條件編譯就行了；
經驗3：方法接口參數和返回值要有普遍性，除去邏輯設計外，C++模板是個好東西；
經驗4：對於自己寫的工具類一定要進行單元測試，你想想，你的工具類也許要提供整個項目，別的項目，給別人，整個項目組，或者更多的人使用，你允許它出錯嗎？
經驗5：多積累，在平時的工作中和學習中積累一個個功能方法，慢慢擴大你的工具類庫；
當你有這麼一把軍刀時
你就酷斃了。
附: 我總結的部分工具類https://github.com/yaocoder/utils
本文出自 “永遠的朋友” 博客，請務必保留此出處http://yaocoder.blog.51cto.com/2668309/846106
