如果您需要从映射中的匹配项开始实例化特定的 Java 类,我会将这些类的值构建器而不是通过反射构建的类名放入,因为它为您提供了更好的灵活性和可能更好的性能。
此类构建器的示例:
public interface BuilderClass<O, P>{
O build(P parameter);
}
public class BuilderSpecificClass<SpecificClass, Object>{
@Override
public SpecificClass build(Object parameter){
return new SpecificClass(parameter);
}
}
然后地图看起来像:
Map<String, BuilderClass<SpecificClass, Object>> map=new HashMap<String, BuilderClass<SpecificClass, Object>>();
map.put("<class_iri>", new BuilderSpecificClass<SpecificClass, Object>());
也就是说,我不清楚你的具体课程是如何工作的,所以可能有更好的方法。你能添加一个你如何构建它们的例子吗?
在汤姆的额外细节之后编辑:
好的,如果我了解您的班级在做什么,那么您已经实现了我描述的方法的一半。您的类基本上包装了 OWL 断言公理集,无论是断言的还是推断的 - 即,您的字段的值来自本体或推理器,并将个人与个人或价值联系起来。您还可以使用本体和推理器填充类实例的方法;这些对应于我上面提出的build()
方法,其中参数是本体和推理器。您可以跳过传递本体管理器,因为 OWLOntologyManager 的实例已经可以通过本体访问:ontology.getOWLOntologyManager()
我在这里要做的就是像我描述的那样创建构建器,并让它们调用您的方法来填充对象。
就性能而言,很难判断是否有任何严重的热点——猜测一下,这段代码应该没有什么特别难的地方。本体是此类问题通常出现的地方。我可以在这堂课中提出以下建议:
private final String personURI = ThesisOntologyTools.PERSON_URI + "Person";
你有几个看起来像这样的成员变量。我相信这些是常量,因此与其在每个实例中都有一个副本,您可以通过将它们设为静态最终来节省内存。
OWLDataProperty isLocationConfirmed = dataFactory.getOWLDataProperty(IRI.create(isLocationConfirmedURI));
您正在以与此类似的方式创建许多对象。请注意,这IRI.create()
将返回一个不可变对象以及dataFactory.getOWLDataProperty()
,因此您不必每次都可以重用此类对象时访问数据工厂。数据工厂生成的所有对象都没有链接到特定的本体并且是不可变的,因此您可以在您的类中自由地重用它们,以减少创建的新对象的数量。数据工厂可能会缓存其中的一些,但其他一些可能会在每次调用时从头开始重新创建,因此减少调用次数应该会提高速度和内存需求。
除此之外,该方法看起来不错。如果所需的内存或速度太高(或太低),您可能需要开始使用分析器来查明问题。如果热点在 OWL API 中,请在 OWLAPI 问题跟踪器中提出问题:-) 我们没有从真实用户那里获得足够的性能报告。