面向 Java 开发人员的 db4o 指南: 结构化对象和集合

核心提示： 清单 9. 嘿，不再是 2001 年了！来为我工作吧！packagecom.tedneward.model;publicinterfaceEmployable{publicbooleanwillYouWorkForUs();}角色和对象一些对象模型将不适合我用接口和继承来模拟 Person 扮演

清单 9. 嘿，不再是 2001 年了！来为我工作吧！

package　com.tedneward.model;　
　
public　interface　Employable　
{　
　　public　boolean　willYouWorkForUs();　
}　

角色和对象

一些对象模型将不适合我用接口和继承来模拟 Person 扮演的角色。例如，假设一个 Employee 的配偶决定也来此公司工作，有必要将他们从系统的 Person 中删除，然后重新插入到 Employee 中吗？ 随着时间的流逝，角色也可能并且经常变化。我们不要期望更改对象的基类和接口类型，以适应角色的转变。

这是一个很普通的争议，如果能够从根本上解决的话，不属于本文讨论的范围。目前我们只能说，我对继承和接口的使用纯粹是出于演示和教学的目的。

要看接口是如何工作的，我需要 Employable 接口的一个实体类继承，并且 — 或许您已经猜测到 — 这意味着创建一个 EmployablePerson 子类型来扩展 Person 和实现 Employable。我不会再次演示这些代码（没有必要演示，除了将 ** EMPLOYABLE ** 添加到 Person 的 toString() 末尾以外， Person 在 EmployablePerson.toString() 方法中）。我也会修改 prepareDatabase() 调用以返回 “Charlotte 是一个 EmployablePerson，而不只是一个 Person” 的事实。

现在，我会编写一个遍历数据库的查询，查找愿意为本公司工作的雇员的配偶或亲人，如清单 10 所示。

清单 10. 有工作了，来看看吧……

@Test　public　void　testEmployableQuery()　
{　
　　List<Employable>　potentialEmployees　=　
　　　　db.query(new　Predicate<Employable>()　{　
　　　　　　public　boolean　match(Employable　candidate)　{　
　　　　　　　　return　(candidate.willYouWorkForUs());　
　　　　　　}　
　　　　});　
　　for　(Employable　e　:　potentialEmployees)　
　　　　System.out.println("Eureka!　"　+　e　+　"　has　said　they'll　work　for　us!");　
}　　　

毫无疑问，Charlotte 被返回了，说明她可能为本公司工作。更好的是，这意味着我引入的任何接口都变成了一种限制查询的新方式，不需要人工添加包含此信息的字段；只有 Charlotte 符合查询条件，因为她实现了这个接口，而其他配偶都没有实现（至少到目前为止）。

结束语

如果说对象和继承就像巧克力和花生酱的话，那对象和多态就好比手和手套。这两个元素就像经理和他/她的高薪一样般配。检索数据时，任何存储对象的系统都不得不将继承的概念引入它的存储媒介和过滤器中。幸运的是，面向对象的 DBMS 使得这很容易实现，而且不必引入新的 query-predicate 术语。从长远看来，引入继承会使 OODBMS 容易使用 得多。