为什么 EMF 中的 eGet 返回 Object 而不是 EObject？
我正在使用 Java 中的 EMF 框架编写一些代码，但它确实很难使用，例如我无法在 EMF 之上实现类似 OCL 的查询 API，而 EMF 是类型安全的。
原因之一是 EStructuralFeature 的 eGet() 仅返回一个 Object，而不是 EObject。因此，我编写的任何内容都必须使用大量空检查、类型检查和类型转换，这是不安全的、不高性能的，并且不能以可重用的方式泛化。
为什么 EMF 不为任意 Object 值生成具有 EObject 包装器的虚拟实现？
即使使用简单的抛出 UnsupportedOperationException 来实现 EObject 和 EClass 接口确实很痛苦（API 太大）。 eContainer() 方法也是如此，这使得向上导航模型变得很痛苦。
I am working on some code using the EMF framework in Java, but it is really hard to use, e.g. I cannot implement OCL-like query API on top of EMF which would be type-safe.
One of the reasons is that eGet() for a EStructuralFeature returns just an Object, not EObject. So anything I would write must use much of null checking, type checking and type casting which is unsafe, not performant and cannot be generalized in a reusable way.
Why doesn't EMF generate dummy implementations with EObject wrappers for arbitrary Object value?
Implementing the EObject and hence the EClass interfaces even with simple throw UnsupportedOperationException is really a pain (the APIs are too big). The same holds for the eContainer() method which makes navigating the model upwards painful.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
相同的方法用于访问简单属性值（可以是任何 Java 类型）并遍历与其他建模对象的关系，这些属性值可以是单值或多值。
EMF 提供了通用机制来检查对象是否是 EClass 的实例，或者 EClass 是否可分配给另一个对象，因此我并没有真正看到这有什么问题。
The same method is used for accessing simple attribute values (which can be of any Java type) and traverse relationships to other modeled objects, and those can be single or multivalued.
EMF provides generic mechanisms for checking whether an object is an instance of an EClass, or if an EClass is assignable to another, so I don't really see the problem with that.
eGet() 方法是 EMF 反射 API 的一部分。由于 EMF 可以包装任何可序列化对象，因此您无法限制此类反射 API 返回的对象。
为什么您需要使用这个反射 API，而不是您的 ecore 模型生成的 Java 实现？这样，您将拥有所有直接的类型良好的 API 来操作您的域对象。
The eGet() method is part of the EMF reflective API. As EMF can wrap any serializable object you cannot restrict the returned object of such a reflective API.
Why do you need to use this reflective API instead of the generated Java implementation of your ecore model? This way you will have all the direct well typed API to manipulate your domain objects.