如果您熟悉Java RDF 和 OWL 引擎 Jena，那么您已经了解了他们的理念，即尽可能将所有内容指定为接口。这意味着Resource、Statement、RDFNode、Property，甚至 RDF Model等，与您可能首先想到的相反，是接口而不是具体的类。
这导致经常使用工厂。由于您无法实例化Property或Model，您必须使用其他东西来为您做这件事——工厂设计模式。
那么，我的问题是，考虑到图书馆旨在服务的内容的性质，使用这种模式而不是传统的类层次系统背后的原因是什么？使用其中任何一个通常都是完全可行的。例如，如果我想要一个内存支持的模型而不是数据库支持的模型，我可以只实例化这些类，我不需要让工厂给我一个。
顺便说一句，我正在编写一个用于处理Pearltrees数据的库，该库以 RDF/XML 文档的形式从他们的网站导出。在我编写这个库时，我有很多选项来定义 Peartrees 数据中存在的关系。Pearltrees 数据的好处在于它有一个非常合乎逻辑的类系统：一棵树由珍珠组成，珍珠可以是 Page、Reference、Alias 或 Root 珍珠。
我的问题来自于试图弄清楚我是否应该在使用 Jena 的图书馆中采用 Jena 哲学，或者我是否应该忽略它，选择我自己的设计哲学并坚持下去。