1.4　何时应当避免使用API

设计并实现API相比编写普通的应用程序代码通常要花费更多精力，因为API的宗旨是提供健壮、稳定的接口供其他开发人员使用。因此，与仅在单一应用程序内部使用的软件相比，API在质量、设计、文档编写、测试、支持及维护方面有更高的要求。

因此，如果编写的是不需要和其他客户端通信的内部模块，那么为模块创建并维护稳定公有接口的额外开销就不值得了，然而这并不是编写劣质代码的理由。为坚持API设计原则而多花费些时间，从长远看来并不浪费时间和精力。

另一方面，假设你是一位想在应用程序中使用第三方API的软件开发人员。前一节讨论了在软件中重用外部API的一些理由，但有时也可能需要避免使用特定的API，在如下这些情况下，你应该花精力自己实现代码或寻找替代的解决方案。

许可证限制。虽然API可以提供所需的各项精巧功能，但是许可证限制可能让你望而却步。例如，如果你想使用GNU GPL（General Public License，通用公共许可证）发布的开源包，那么就必须使用GPL发布所有衍生作品。如果在程序中使用这个包，就必须发布整个应用程序的源代码，这是商业应用可能不会接受的约束。其他的许可证（如GNU Lesser General License GPL，LGPL）就更加宽松些，在软件库中也更加常见。许可证问题的另一种体现是：商业API的费用对你的项目来说可能过于昂贵，或者许可条款可能过于严格，比如要求向每位开发者甚至每位用户收取许可费用。

功能不匹配。虽然API看似能够解决所面临的问题，但是它有可能以一种与应用程序约束或功能需求不匹配的方式执行。例如，可能你正在开发一个图像处理工具，想要提供傅里叶变换功能。虽然有许多现成的FFT（Fast Fourier Transform，快速傅里叶变换）的实现，但是其中大多数是1D算法，而处理2D图像数据需要使用2D FFT。此外，许多2D FFT算法只能在大小是2的整数幂的数据集上工作（如256×256或512×512）。或许你找到的API不能在必须支持的平台上运行，或者它不能满足你对程序制定的性能标准。

缺少源代码。虽然有许多开源API，但是有时符合要求的最佳API可能是闭源产品。也就是说，只提供接口的头文件，而背后的C++(www.cppentry.com)源文件并不同库一起发布。这有几项重要的影响，其中之一就是当库中存在错误时，不能通过检查源代码的方式定位问题。对于跟踪错误进而找到解决方案来说，阅读源代码是一个很重要的方法。

进一步说，不能访问API的源代码就丧失了通过修改源代码修复错误的能力。这意味着软件项目的进度可能会受到所使用的第三方API中不可预期问题的不利影响，并且需要等待该API的所有者处理你的错误报告并发布修复补丁。

缺乏文档。虽然API看似可以完全满足应用程序的需求，但是如果API的文档编写拙劣或根本没有文档，那么你最好再去寻找别的解决方案。在这种情况下，有可能是API的用法不清楚影响了它的使用，也有可能是你无法确定特定情况下API的行为，甚至可能是你根本无法信任那些连花点儿时间解释代码如何使用都做不到的开发者。