Tl;博士：坚持使用粗体文字。
其他人提供的 库可以保存很多编程时间，因为人们不必解决其他人已经遇到的问题。此外，他们经常执行某些任务更高效，而不是自己实现的任务。在缺点方面，会向程序添加依赖，这可能会导致许可问题，在其他计算机上编译等等。图书馆的发展也可能会干扰自己代码的发展。在极端情况下，经过一段时间限制到功能后，库提供的意思是即使是小扩展也可能要求程序员重写一半的库。在这种情况下，人们可能更愿意用不同的库交换库。
此时，如果整个代码混乱而调用库，则可能会遇到很大的麻烦。为了防止这样的问题，可以从一开始就在外部库周围写一个包装器，以便库更改减少到更改包装器，而且理论上不需要触及其他代码。
但实际上，调用包装器的接口可能 兼容与“new”库。此外，库可能会使用数据结构 直接兼容与自己程序中的数据类型。然后需要重新组织数据，并且可能会发生大量复制，而这在以前是不必要的。
问题：
示例：
我研究了一个庞大的程序，其中线性代数的问题无处不在。最近，我们开始转向Eigen，这是一个具有广泛线性代数功能的高效库。 Eigen带有自己的数据对象。现在代码中存在大量std::vector<double>个对象，需要用Eigen的VectorXd替换才能与Eigen很好地协作。完成所有这些替换工作将是一项神奇的工作。但是，如果某些点上的Eigen不是理想的解决方案，那么撤消这些更改可能会更加有效。现在我不确定是否编写一个自己的包含Eigen数据类型的向量类实际上会减少一天库交换时的工作量，或者我是否会以这种方式产生更多问题。
答案 0 :(得分：1)
一些建议：
选择大型成熟项目使用的库。只要具有较小的用户群，图书馆作者只能使用API。像SQLite这样的库在大型项目（如Firefox）中使用，根本无法通过进行不兼容的更改来惹恼用户。
如果可以，请选择一个开源库（如果您的项目是闭源的，请选择LGPL）。这样，如果库开发停止或偏离目标，您可以分叉最后一个兼容版本并继续自己向库中添加必要的功能。它会比在中途换到不同的图书馆便宜得多。
包装库类型无济于事。由于类型更改，切换库并不痛苦，但因为整个程序结构可能需要适应新库。