Pourquoi eGet dans EMF renvoie Object plutôt que EObject?

Question

Je travaille sur du code en utilisant le framework EMF en Java, mais il est vraiment difficile à utiliser, par exemple. Je ne peux pas implémenter une API de requête de type OCL au-dessus de EMF qui serait sécurisée.

L'une des raisons est que eGet() pour un EStructuralFeature renvoie simplement un Object, et non EObject. Donc, tout ce que j'écrirais doit utiliser une grande partie des vérifications nuls, des vérifications de types et des transtypages qui sont dangereux, non performants et qui ne peuvent pas être généralisés de manière réutilisable. Pourquoi les champs électromagnétiques ne génèrent-ils pas des implémentations fictives avec des enveloppes EObject pour une valeur arbitraire Object?

L'implémentation des EObject et donc les interfaces EClass même avec le simple lancer UnsupportedOperationException est vraiment pénible (les API sont trop grandes). La même chose vaut pour la méthode eContainer() qui rend la navigation du modèle douloureuse.

Answer 1

La même méthode est utilisée pour accéder aux valeurs d'attributs simples (qui peuvent être de n'importe quel type Java) et pour traverser les relations avec d'autres objets modélisés, et celles-ci peuvent être uniques ou à valeurs multiples. EMF fournit des mécanismes génériques pour 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 avec cela.

Answer 2

La méthode eGet() fait partie de l'API réflective EMF. Comme EMF peut envelopper n'importe quel objet sérialisable, vous ne pouvez pas restreindre l'objet retourné d'une telle API réfléchissante. Pourquoi avez-vous besoin d'utiliser cette API réflective à la place de l'implémentation Java générée de votre modèle ecore? De cette façon, vous aurez toute l'API directement typée pour manipuler les objets de votre domaine.