对工具类的思考

对于工具类，我将近两个星期一直在进行研究和揣摩，很多理解随着时间在不断的深化和淬炼，也发现以往理解中的很多错误。

对于工具类， 本身并没有本身并没有太复杂的逻辑，工具类对于整个项目来说相对 独立，起到的作用，是给其他部分提供独立的功能。从这一点上看，工具类应该做到高度内聚，以及极低的耦合度，就是说，工具类的任何一个类，都是像插件一般，是作为项目工具使用，其中不能与项目逻辑产生耦合。当项目中需要的单元功能出现重复出现的趋势，便将这种工具性质的重复予以归纳，形成可复用的单元，做到最大化重用，并且这么做可以保持逻辑的一致性。

除去以上的因素，工具类还有另外一个非常重要的职责，便是对底层API接口的封装，对底层API的使用都必须经过工具类的一系列包装，然后调用工具类使用，坚决避免在项目中大量使用该语言自身提供的API。这么做，是为了保持项目的稳定性，并且摆脱对第三方API的大量依赖，将语言本身提供的API经过工具类的包装，项目本身需要的功能，便只从工具类中得到。如果要更换另一种语言，或者语言本身的特性发生变化，或者对语言本身的API接口发生变动，那么直接在工具类中进行包装修改即可，避免过于依赖任何一种API和语言以及平台。

这也就引申出对于底层封装的一些处理方式，如果要去除第三方的依赖，或者第三方提供的接口可能发生变动，最好使用装饰模式，将第三方的API予以包装，这样即使换用另一套提供相同功能的API，也不会对上层发生影响。在数据库的处理中，这种方式非常有效。对于数据库的任何操作，以及对于 数据库的返回集的操作，都进行了大量的包装，但是还应注意，数据库的操作已经不是工具类这种独立，而是持久化存储的一层，牵扯到其自身的处理方式，不在此处讨论之列。

在处理工具类时，有 一个必须注意到的特点，工具类一般是项目最初完成的模块，也就是说，工具类实现在项目需要之前，那么工具类就不得不预先对项目的做一下预测，推测会遇到哪些功能，然后根据需要对API进行一些封装处理，组合成项目需要的功能。但这就意味着，要将未来发生的事情提前规划到现在，这违背了XP编程中非常强调的一点：如无必要，勿增实体。提前将未来可能发生的事情编写进项目中在实现上并不具有太大困难，问题就出在，这些针对未来预防的代码，会不自觉的和现有的代码产生关联，一个方法写出来之后，就避免不了被其他方法调用，渐渐的，本来是针对预防性的举措会成为项目 冗余和高耦合度的一个累赘。把鱼按上双腿并不难，但是要想让有了双腿的鱼行走，还要有必须具备的各种因素，也就是说想让鱼行走，还要有能让鱼行走的外界条件，但是未来总是充满变动，现有的预防措施会对现有的功能产生冲击。换句话说，为什么想要一条会行走的鱼呢？

但是如果不预先考虑未来可能发生的事情，一旦将来新的需求迫使工具类必须进行扩充，若在一开始时没有严格确定功能的逻辑性，那么渐渐的工具类中将会出现混乱的和相似的功能组成，首先在命名上就会出现极其容易混淆的情况，而且新的需求不断的扩充进工具类之后，极其容易在逻辑上早上困惑，这需要有自己的一些编程规范来予以控制混乱的程度。