لماذا EGET في EMF إرجاع الكائن بدلاً من eObject؟

Question

أنا أعمل على بعض التعليمات البرمجية باستخدام إطار EMF في Java ، لكن من الصعب حقًا استخدامها ، على سبيل المثال ، لا يمكنني تطبيق API الشبيه بـ OCL على رأس EMF والتي ستكون آمنة من النوع.

أحد الأسباب هو ذلك eGet() ل EStructuralFeature يعود فقط Object, ، ليس EObject. لذلك يجب أن يستخدم أي شيء سأكتبه الكثير من الفحص الفارغ ، والتحقق من الكتابة والنوع غير الآمن ، وليس أداءً ولا يمكن تعميمه بطريقة قابلة لإعادة الاستخدام.

لماذا لا تولد EMF تطبيقات وهمية EObject أغلفة التعسفية Object القيمة؟

تنفيذ EObject وبالتالي EClass واجهات حتى مع رمي بسيط UnsupportedOperationException هو حقا ألم (واجهات برمجة التطبيقات كبيرة جدا). نفس الشيء يحمل ل eContainer() الطريقة التي تجعل التنقل في النموذج مؤلمة لأعلى.

Answer 1

يتم استخدام نفس الطريقة للوصول إلى قيم السمات البسيطة (والتي يمكن أن تكون من أي نوع Java) وتجتاز العلاقات مع الكائنات النمطية الأخرى ، ويمكن أن تكون واحدة أو متعددة.

يوفر EMF آليات عامة للتحقق مما إذا كان الكائن هو مثيل لـ ECLASS ، أو إذا كان ECLASS قابلاً للتخصيص لآخر ، لذلك لا أرى المشكلة حقًا في ذلك.

Answer 2

طريقة EGT () هي جزء من API العاكس EMF. نظرًا لأن EMF يمكن أن يلف أي كائن قابل للتسلسل ، لا يمكنك تقييد الكائن الذي تم إرجاعه من واجهة برمجة التطبيقات العاكسة.

لماذا تحتاج إلى استخدام واجهة برمجة التطبيقات العاكسة هذا بدلاً من تنفيذ Java الناتج عن نموذج ECORE الخاص بك؟ وبهذه الطريقة ، سيكون لديك كل واجهة برمجة التطبيقات المباشرة المكتوبة جيدًا لمعالجة كائنات المجال الخاصة بك.