©著作权归作者所有：来自51CTO博客作者一个叫大姚的工程师的原创作品，请联系作者获取转载授权，否则将追究法律责任
（说明：标题所说的“类”;，并不一定是指面向对象的类，而是泛指有着特定作用的代码文件）
我写代码有个习惯，在一个工程建立之初，首先会建一个“工具代码”目录，在这个目录里会放入多种工具“类”，比如提供文件操作的，字符串转换的，dump文件输出（windows），注册表操作（windows），计时器服务......等等。别小看这些工具类或方法，举个简单的例子，就拿ANSI和UNICODE字符的转换来说，绕晕了不少人吧。文件操作，很多工程都会遇见吧，何不把其封装成一个工具“类”，随时加入各个工程进行使用，多的就不举例了，总之可以把我们认为能提供某种功能的代码实现都封装成工具类供其他工程调用，你想想看，这像不像一把瑞士×××，开始也许只有刀子和起子，慢慢的变成一把集有各种工具的超级×××，怎么样，是不是用起来很爽。
但是，请注意，要是你用一把劣质的×××，割东西刀刃坏了，剪东西剪不动，......你肯定会发出“坑爹”的抱怨。写工具类也是如此，这些工具类一定要是高质量的，稳定的，健壮的，最好还是跨平台的。
下面我来谈谈我写工具类的一些经验：
经验1：不要重复造轮子，找别人写好的。注意了，不是说那些从网上随便搜来的，当然也不排除有高质量的。我呢，喜欢在著名的开源代码里或者有些泄露的著名商业代码中搜索含有util关键字的代码文件，很壮观，一堆堆的，下面就是自己对这些工具类进行取舍了，反正我还是比较相信高质量的开源代码和商业软件的，一般取之就用，目前还未发生过不良反应。
经验2：能跨平台的的尽量跨平台，毕竟我们现在都比较重视跨平台开发了，我呢，多喜欢用STL，boost，或者posix接口实现。至于依赖于系统API的，加上系统标识的条件编译就行了；
经验3：方法接口参数和返回值要有普遍性，除去逻辑设计外，C++模板是个好东西；
经验4：对于自己写的工具类一定要进行单元测试，你想想，你的工具类也许要提供整个项目，别的项目，给别人，整个项目组，或者更多的人使用，你允许它出错吗？
经验5：多积累，在平时的工作中和学习中积累一个个功能方法，慢慢扩大你的工具类库；
当你有这么一把×××时你就酷毙了。
附: 我总结的部分工具类 https://github.com/yaocoder/utils
6赞 1收藏 评论 举报相关文章
