关于工具包（Utils）的重新思考

Posted 2021-06-27 sp42a

工具包/助手包（英文多见于 Utils、Helpers、Tools）是框架的基础构成部分。随着时间的推移，我们的软件代码写得越来越多，API 中两次或两次以上使用到代码，可视为通用的逻辑，可考虑将其抽出来，封装形成公共调用的方法。至于出现多少次才能归纳到工具库，开发者必须有一个清醒的认识：如果出现少但也重构到公共库 API，那么这些所谓重用的 API 会显得非常琐碎，举一个反模式的例子：但凡是出现两次都算，那么是不是都要抽取到工具包里面呢？可以预见，这种“包罗万有”导致不但维护费力且调用者也觉得烦琐，少封装不如无封装；如果那个逻辑非常重要，有显著性等的因素，例如特定的算法，那么即使出现一次也可以归并到 API 里面去。总之，没有一个特定的量，是一种平衡，在整体的运行机制来说是统一的，可以抽取成公共的部分，但是有一部分又会业务性非常强，需要在实际做业务的时候进行扩展。

工具包里的工具类多为公开的、静态（static）方法，例如 StringUtils、IOUtils,、FileUtils……可以说是一个个小的实用函数（Utility 或称 Helper、Tools）。不过也不全是静态方法，也有大的组件，比如日志组件也归类到实用工具包中。

工具包的方法可以在程序中直接调用，不会生成实例对象。因此包含工具方法的类本身不需要实例化，所以工具方法的执行也是无状态的（stateless），也就是说，除了输入的参数和其他静态成员外，没有其他元素可以改变函数返回的结果。熟悉 C 语言的用户对静态方法倍感熟悉，在于静态方法本身就跟 C 语言的面向过程的函数很相似。另外一方面讲，这导致有人批评仍使用面向过程会不符合面向对象的思想，于是建议单例模式（Singleton）代替静态方法。不过在笔者看来，工具方法代码应该简易、简洁多一些，故倾向于采用静态的方法。

理论上工具类应该可以做到与特定环境脱离，只要是 Java 运行环境便可使用，不限定特定的 Web、Swing、android 或其他。实际上 AJAXJS 目标亦如此，不过因为尚未测试的缘故，很多情况考虑不到，不能百分百达成。