Por que o eget no EMF retorna objeto em vez de eoBject?

Question

Estou trabalhando em algum código usando a estrutura EMF em Java, mas é realmente difícil de usar, por exemplo, não posso implementar a API de consulta do tipo OCL no topo da EMF, que seria segura do tipo.

Uma das razões é que eGet() para EStructuralFeature retorna apenas um Object, não EObject. Portanto, qualquer coisa que eu escrevia deve usar grande parte da verificação nula, verificação de tipo e fundição de tipo que é insegura, não performante e não pode ser generalizada de maneira reutilizável.

Por que a EMF não gera implementações fictícias com EObject invólucros para arbitrários Object valor?

Implementando o EObject e daí o EClass interfaces mesmo com arremesso simples UnsupportedOperationException é realmente uma dor (as APIs são muito grandes). O mesmo vale para o eContainer() Método que torna doloroso a navegação no modelo.

Answer 1

O mesmo método é usado para acessar valores de atributo simples (que podem ser de qualquer tipo Java) e atravessar relacionamentos com outros objetos modelados, e esses podem ser únicos ou multivalugos.

A EMF fornece mecanismos genéricos para verificar se um objeto é uma instância de um eclass ou se um eclass é atribuível a outro, então eu realmente não vejo o problema com isso.

Answer 2

O método EGET () faz parte da API reflexiva EMF. Como a EMF pode envolver qualquer objeto serializável, você não pode restringir o objeto retornado de uma API reflexiva.

Por que você precisa usar essa API reflexiva em vez da implementação Java gerada do seu modelo Ecore? Dessa forma, você terá toda a API direta bem digitada para manipular seus objetos de domínio.