Java 黑板构造块多态性还是接口？

如果我误解了这两个概念，请纠正我。多态性似乎以多种形式表示对象，例如用户可以是基类，学生或教师可以是子类。它们仍然属于user类型，但有自己的实现。接口提供了与子类中的基类交互的大纲。多态性可以与接口结合使用，有时是必要的

---

基于这种理解，我正在为现有的学习管理系统创建一个附加组件。它有自己的库与不同的对象交互，例如用户、年级或课程信息。库中的一些对象与库中要实例化或生成值的其他对象耦合。例如，需要课程ID号来获取成绩信息。库的API不明确或根本不存在。多态性和/或接口是否会使我在项目中使用这些库变得更容易，即使我对API不是很确定？在这种类型的项目上使用多态性和/或接口，单元测试会是什么样子？一般来说，在使用文档质量较差的第三方库进行开发时，最佳做法是什么？

黑板构建块API旨在实例化并调用方法来访问数据。扩展Blackboard类时有一些实例是有意义的，但一般来说，它们的存在只是为了让您能够访问数据

在全面披露中，我为Blackboard工作，最近我加入了文档团队，以帮助继续构建位于的开发人员文档和资源部分

在Learn->Administrator->April Release->Developer Resources下有许多文档可用。我们还每隔周三在美国东部夏令时上午11点召开开发者办公时间会议。开发者资源下的社区文件夹将为您提供加入所需的信息。它们是免费的，对任何人开放

多态性和/或接口是否会使这些更容易使用 我的项目中的库，即使我对API不是很确定

并非如此，API的文档和API的设计是API变得更易于使用的主要方式。使用API是一项学习任务，文档就像一个很好的教程或课程，而API设计的改进就像是简化要学习的材料

使用多态和/或接口进行单元测试会是什么样子 关于这类项目

在大多数情况下，单元测试都是类似的，从某种意义上说，您可以调用一个方法，或者对一个对象调用多个方法并检查结果

使用多态性，您主要测试继承树底部的类，使用接口，同样，您主要测试继承树底部的类。这是因为在进行单元测试时，您确实无法以有意义的方式实例化抽象类或接口

一般来说，与第三方合作开发时的最佳实践是什么 文档质量差的库

一般来说，最佳实践是编写小段代码来验证您的假设，然后运行它们，看看您对其库工作方式的假设是否正确

其他技术包括下载库的源代码并阅读（如果有）。以这种方式编写单元测试来“测试库”可能很有用，但有时库的结构并不能很好地实现这一点

有时可以通过其他方式获得文档，例如购买一本介绍图书馆的书。有时，您可以从图书馆的供应商处接受“培训”课程。有时，您可以找到正在使用库的其他人并向他们提问（这通常包括特定于库的用户组或邮件列表）。有时，您可以访问库的bug跟踪系统，并可以从bug提交（或拒绝bug提交，表明正确使用函数的方式等）中找到详细信息。有时，您可以找到使用相同库的其他项目，并阅读它们的源代码以确定似乎有效的使用模式

---

库通常是为使用而编写的，但并非每个人都擅长编写要使用的库。有时作者提供信息，而你只是不知道信息在哪里，有时作者缺乏必要的能力，无法持有不同的观点，也无法向你展示如何有效地使用信息。一般来说，太难使用的库很少被使用，最终会被遗忘和未使用。

多态性和继承是相辅相成的，是面向对象编程的两个方面，而不是可替换的技术。有点像颜色和高度不能互相替代。为了获得多态性行为，您通常以抽象的方式使用某些东西，但它的行为是以特定的方式进行的。你以一种抽象的方式使用它，

animal.makeSound（）

，这需要继承，并且它的行为特别明确（因为

newdog（）

被分配给了animal，

animal.makeSound（）

发出声音

吠叫

。