Pourquoi eget des rendements EMF objet plutôt que EObject?

Question

Je travaille sur un code en utilisant le framework EMF en Java, mais il est vraiment difficile à utiliser, par exemple Je ne peux pas mettre en œuvre OCL comme API de requête sur le dessus des champs électromagnétiques qui serait de type sécurisé.

L'une des raisons est que eGet() pour un rendement de EStructuralFeature juste un de Object, non EObject. Donc, tout ce que je voulais écrire doit utiliser beaucoup de contrôle nul, la vérification du type et de la coulée de type qui est dangereux, pas et ne peut pas performant être généralisé d'une manière réutilisable.

Pourquoi ne génère pas EMF implémentations fictives avec des enveloppes de EObject pour valeur Object arbitraire?

Mise en œuvre du EObject et donc les interfaces EClass même avec UnsupportedOperationException simple jet est vraiment une douleur (les API sont trop grandes). La même chose vaut pour le procédé de eContainer() qui rend la navigation vers le haut le modèle du joueur.

Answer 1

Le même procédé est utilisé pour accéder à des valeurs d'attributs simples (qui peuvent être de tout type Java) et les relations traversent à d'autres objets modélisés, et ceux qui peuvent être à simple ou à valeurs multiples.

EMF fournit des mécanismes génériques permettant de vérifier si un objet est une instance d'un EClass, ou si un EClass est assignable à un autre, donc je ne vois pas vraiment le problème.

Answer 2

La méthode eget () fait partie de l'API de réflexion de la FEM. Comme EMF peut envelopper tout objet sérialisable vous ne pouvez pas limiter l'objet retourné d'une telle API de réflexion.

Pourquoi avez-vous besoin d'utiliser cette API de réflexion au lieu de l'implémentation Java générée de votre modèle Ecore? De cette façon, vous aurez toutes les API bien tapé directement à manipuler vos objets de domaine.