Clean Code - 边界

三方代码的使用

• 前言

  在错误处理的章节（依调用者需要定义异常类这一小节），我们曾经见到过对第三方 API 异常进行封装，定义出适合自己系统的异常类这种操作。其实不光是异常，针对三方代码的其他特性进行类似的适配处理也是维持系统边界整洁的重要一环。

• 三方代码可能带来的问题

  三方程序包和框架提供者追求普适性，以便让它提供的功能能在尽量多的环境中工作，吸引广泛的用户。但是使用者则想要集中满足特定需求的接口。带来的问题就是三方程序中有若干功能是使用者系统里面不想要或者需要加以限制的，如果使用者不加控制地引入三方程序，将会给系统带来很大的不稳定性。

• 例子

  • 引出：

    书中作者给出了 Java 中 Map 接口的例子。Map 本身拥有很多接口来让用户对数据进行操作，但是删除数据是需要谨慎处理的事情，假设在系统中，我们不加限制地使用 Map 来传递重要数据，哪天其 Clear() 函数被调用了，那么系统可能就会出现极大不确定性风险。

  • 解决：

    最简单的方式就是根据系统自身的需求，对 Map 进行封装，开放我们自定义的接口，接口实现才是真正的对 Map 进行的操作。当然了，作者并不建议如此做法，最好的做法就是避免传递 Map ，如果把 Map 换做更三方的东西，换句话说就是让三方的东西更少地侵入到我们的系统代码中

• 学习性测试

  • 引出：

    在利用三方代码时，该从何入手？

  • 建议：

    作者的建议是先测试，而且是学习性测试，即在把三方代码真正搬到我们的系统之前，应该先测试其接口功能。以便更加了解三方代码的特性，并且检查三方代码是否能符合系统实际需求。并且测试的方式是学习性测试，通过测试的方法来学习三方代码的使用。

使用尚不存在的代码

• 前言

  开发中你或多或少会面对未知的代码编程。尤其是在团队合作项目中，你开发的模块也许会依赖别人开发的模块，但当别人的模块还没开发出来之前，你需要的不是等待，不应该受其阻碍。

• 你需要做什么？

  • 编写虚构接口，后期用适配器模式思想进行整合，整合往往是最后一步
  • 为虚构接口编写虚构数据进行测试

小结

• 控制你能控制的东西，比控制你不能控制的东西要好得多
• 对三方的东西进行适度适配封装很有必要，以保证减少三方代码对自己代码产生的影响