如果我对这两个概念有误解，请纠正我。多态性似乎以多种形式表示对象，例如用户可以是基类，学生或教师可以是子类。他们仍然是用户类型，但有自己的实现。接口提供了与子类中的基类交互的大纲。多态性可以与接口结合使用，有时可能是必要的。
有了这种理解，我正在为现有的学习管理系统创建一个附加组件。它有自己的库来与不同的对象进行交互，例如用户、成绩或课程信息。库中的一些对象与库中的其他对象耦合以被实例化或产生一个值。一个例子是需要课程 ID 号来获取成绩信息。库的 API 模糊或不存在。即使我对 API 不太确定，多态性和/或接口是否会使在我的项目中使用这些库变得更容易？在这种类型的项目中使用多态和/或接口进行单元测试会是什么样子？一般来说，使用文档较差的第三方库进行开发时，最佳实践是什么？
Blackboard Building Block API 旨在实例化并调用方法来访问数据。在某些情况下扩展 Blackboard 类是有意义的，但一般来说，它们只是为了让您访问数据而存在。
完全公开，我在 Blackboard 工作，最近加入了文档团队，以帮助继续在https://help.blackboard.com上构建开发人员文档和资源部分。
在 Learn->Administrator->April Release->Developer Resources 下有许多可用的文档。我们还每隔一个星期三在美国东部时间上午 11 点举行开发人员办公时间。开发人员资源下的社区文件夹将为您提供加入所需的信息。它们是免费的，对任何人开放。
即使我对 API 不太确定，多态性和/或接口是否会使在我的项目中使用这些库变得更容易？
并非如此，围绕 API 的文档和 API 的设计是 API 变得更易于使用的主要方式。使用 API 是一项学习任务，文档就像一个很好的教程或课程，而 API 设计的改进就像简化要学习的材料。
在这种类型的项目上使用 Polymorphisim 和/或接口进行单元测试会是什么样子？
在大多数情况下，单元测试是相似的，从某种意义上说，您可以调用一个方法或对象上的多个方法并检查结果。
使用 Polymorphisim，您主要测试继承树底部的类，使用接口，同样您主要测试继承树底部的类。那是因为您确实无法以在单元测试时有意义的方式实例化抽象类或接口。
一般来说，使用文档较差的第三方库进行开发时，最佳实践是什么？
一般来说，最佳实践是编写一小段代码来验证您的假设，然后运行它们以查看您对他们的库如何工作的假设是否正确。
其他技术包括下载库的源代码并阅读它（如果可用）。以这种方式编写单元测试来“测试库”可能很有用，但有时库的结构并没有很好地使这变得容易。
有时可以通过其他方式获得文档，例如通过购买向您介绍图书馆的书籍。有时您可以从图书馆的供应商那里参加“培训”课程。有时您可以找到其他正在使用图书馆的人并向他们提问（这通常包括图书馆特定的用户组或邮件列表）。有时您可以访问库的错误跟踪系统，并可以从错误提交中找到详细信息（或错误提交的拒绝表明使用函数的正确方法等）。有时您可以找到使用相同库的其他项目并阅读它们的源代码以确定似乎有效的使用模式。
库通常是为了使用而编写的，但并不是每个人都擅长编写要使用的库。有时作者提供了信息，而您只是不知道它在哪里，有时作者缺乏必要的能力来持有不同的观点，并且从不向您展示如何有效地使用它。通常，太难使用的库很少被使用，最终被遗忘和使用。