Blackboard Building Block 多态性还是接口？
Blackboard Building Block Polymorphism or Interface?
如果我对这两个概念有误解，请指正。多态性似乎以多种形式表示一个对象，例如用户可以是一个基础class，而学生或老师可以是一个子class。他们仍然是用户类型，但有自己的实现。接口提供了与来自子 class 的基础 class 交互的大纲。多态性可以与接口结合使用，有时是必要的。
基于这种理解，我正在为现有的学习管理系统创建一个附加组件。它有自己的库来与不同的对象交互，如用户、成绩或课程信息。库中的一些对象与库中的其他对象耦合以被实例化或产生值。一个例子是需要课程 ID 号来获取成绩信息。图书馆的 API 不明确或 none 存在。多态性 and/or 一个接口是否可以让我更容易在我的项目中使用这些库，即使我不太确定 API？在此类项目上使用多态性 and/or 接口进行单元测试会怎样？一般而言，在使用文档不完善的第三方库进行开发时，最佳做法是什么？
Blackboard Building Block API 用于实例化和调用方法来访问数据。在某些情况下，扩展 Blackboard class 是有意义的，但一般来说，它们的存在只是为了让您能够访问数据。
坦白说，我在 Blackboard 工作，最近我加入了文档团队，帮助继续构建 https://help.blackboard.com 上的开发人员文档和资源部分。
在“学习”->“管理员”->“4 月发布”->“开发人员资源”下有许多可用的文档。我们还每隔一个星期三在美国东部时间上午 11 点举行开发人员办公时间。 Developer Resources 下的 Community 文件夹将为您提供加入所需的信息。它们是免费的，对任何人开放。
Would Polymorphism and/or an Interface make it easier to use these
libraries in my project even though I am not so sure about the API?
并非如此，围绕 API 的文档和 API 的设计是 API 变得更易于使用的主要方式。使用 API 是一项学习任务，文档就像一个很好的教程或课程，而 API 设计的改进就像简化要学习的 material。
What would unit testing be like using Polymorphisim and/or an Interface
on this type of project?
在大多数情况下，单元测试是相似的，在某种意义上，您将调用一个方法，或对一个对象调用多个方法并检查结果。
使用 Polymorphisim，您主要测试继承树底部的 classes，使用接口，您再次主要测试继承树底部的 classes。那是因为您确实无法以在单元测试时有意义的方式实例化抽象 class 或接口。
In general, what is the best practice when developing with third party
libraries that have poor documentation?
一般来说，最佳做法是编写小段代码来验证您的假设，然后 运行 看看您的假设是否正确，您认为他们的库是如何工作的。
其他技术包括下载库的源代码并阅读它（如果可用）。将单元测试写入 "test the library" 可以以这种方式使用，但有时库的结构不是很好，无法使这变得容易。
有时可以通过其他方式获得文档，例如购买介绍图书馆的书籍。有时您可以从库的供应商处获取 "training" classes。有时您可以找到正在使用图书馆的其他人并向他们提问（这通常包括图书馆特定的用户组或邮件列表）。有时您可以访问库的错误跟踪系统，并可以从提交的错误中找到详细信息（或拒绝提交的错误表明使用函数的正确方法等）。有时您可以找到使用相同库的其他项目并阅读它们的源代码以确定似乎有效的使用模式。
库通常是为使用而编写的，但并不是每个人都擅长编写要使用的库。有时作者提供了信息而你只是不知道它在哪里，有时作者缺乏必要的能力来拥有不同的观点并且从不告诉你如何有效地使用它。通常，太难使用的库很少被使用，最终被遗忘和不用。
如果我对这两个概念有误解，请指正。多态性似乎以多种形式表示一个对象，例如用户可以是一个基础class，而学生或老师可以是一个子class。他们仍然是用户类型，但有自己的实现。接口提供了与来自子 class 的基础 class 交互的大纲。多态性可以与接口结合使用，有时是必要的。
基于这种理解，我正在为现有的学习管理系统创建一个附加组件。它有自己的库来与不同的对象交互，如用户、成绩或课程信息。库中的一些对象与库中的其他对象耦合以被实例化或产生值。一个例子是需要课程 ID 号来获取成绩信息。图书馆的 API 不明确或 none 存在。多态性 and/or 一个接口是否可以让我更容易在我的项目中使用这些库，即使我不太确定 API？在此类项目上使用多态性 and/or 接口进行单元测试会怎样？一般而言，在使用文档不完善的第三方库进行开发时，最佳做法是什么？
Blackboard Building Block API 用于实例化和调用方法来访问数据。在某些情况下，扩展 Blackboard class 是有意义的，但一般来说，它们的存在只是为了让您能够访问数据。
坦白说，我在 Blackboard 工作，最近我加入了文档团队，帮助继续构建 https://help.blackboard.com 上的开发人员文档和资源部分。
在“学习”->“管理员”->“4 月发布”->“开发人员资源”下有许多可用的文档。我们还每隔一个星期三在美国东部时间上午 11 点举行开发人员办公时间。 Developer Resources 下的 Community 文件夹将为您提供加入所需的信息。它们是免费的，对任何人开放。
Would Polymorphism and/or an Interface make it easier to use these libraries in my project even though I am not so sure about the API?
并非如此，围绕 API 的文档和 API 的设计是 API 变得更易于使用的主要方式。使用 API 是一项学习任务，文档就像一个很好的教程或课程，而 API 设计的改进就像简化要学习的 material。
What would unit testing be like using Polymorphisim and/or an Interface on this type of project?
在大多数情况下，单元测试是相似的，在某种意义上，您将调用一个方法，或对一个对象调用多个方法并检查结果。
使用 Polymorphisim，您主要测试继承树底部的 classes，使用接口，您再次主要测试继承树底部的 classes。那是因为您确实无法以在单元测试时有意义的方式实例化抽象 class 或接口。
In general, what is the best practice when developing with third party libraries that have poor documentation?
一般来说，最佳做法是编写小段代码来验证您的假设，然后 运行 看看您的假设是否正确，您认为他们的库是如何工作的。
其他技术包括下载库的源代码并阅读它（如果可用）。将单元测试写入 "test the library" 可以以这种方式使用，但有时库的结构不是很好，无法使这变得容易。
有时可以通过其他方式获得文档，例如购买介绍图书馆的书籍。有时您可以从库的供应商处获取 "training" classes。有时您可以找到正在使用图书馆的其他人并向他们提问（这通常包括图书馆特定的用户组或邮件列表）。有时您可以访问库的错误跟踪系统，并可以从提交的错误中找到详细信息（或拒绝提交的错误表明使用函数的正确方法等）。有时您可以找到使用相同库的其他项目并阅读它们的源代码以确定似乎有效的使用模式。
库通常是为使用而编写的，但并不是每个人都擅长编写要使用的库。有时作者提供了信息而你只是不知道它在哪里，有时作者缺乏必要的能力来拥有不同的观点并且从不告诉你如何有效地使用它。通常，太难使用的库很少被使用，最终被遗忘和不用。