Differences between revisions 1 and 5 (spanning 5 versions)
Deletions are marked like this. | Additions are marked like this. |
Line 1: | Line 1: |
Create an operation inside an interface |
== Create an operation inside an interface == With Model Interface |
Line 8: | Line 10: |
The big drawback is that when a new model implementation is introduced that will introduce new model element types and the MetaTypes interface will continually need to adapt to provide a new getSomething() operation. With Repository API |
|
Line 10: | Line 15: |
MetaType operationType = MetaTypes().getOperation(); | MetaType operationType = repository.getMetaType("Operation"); |
Line 14: | Line 19: |
A MetaType is requested from the Repository by a string identifier. That MetaType has the functionality to create instances. | |
Line 15: | Line 21: |
Add an existing element to another - everything can be done with a far reduced API (one add method) and less verbose |
One criticism of this technique is compile time safety. To help with this it would be possible to create a utility class with all the model element types already defined. This would be external to the repository API though. The example below uses a utility class called Type that has all the element types predefined as constants. {{{#!java numbering=off Element myOperation = Type.OPERATION.createElement(myInterface); }}} In reality however there will be limited places where such code will exist (reverse engineering is the main candidate). For this utility methods can be created or a RepositoryFacade built. Most places would more likely be data driven {{{#!java numbering=off Element myElement = myMetatype.createElement(container); }}} == Add an existing element to another == With Model Interface Separate methods have been provided for each model element type. Once again this API will have to adapt when new model element are introduced. |
Line 23: | Line 47: |
With Repository API | |
Line 29: | Line 54: |
== Recognising Element Type == With Model Interface Separate methods have been provided for each model element type. Once again this API will have to adapt when new model element are introduced. {{{#!java numbering=off Model.getFacade().isANamespace(myElement); Model.getFacade().isAFeature(myElement); Model.getFacade().isAParameter(myElement); }}} With Repository API there is only one method to ever be aware of {{{#!java numbering=off myElement.instanceOf(Type.NAMESPACE); myElement.instanceOf(Type.FEATURE)); myElement.instanceOf(Type.PARAMETER); }}} ---- CategoryFurtherDevelopment |
Create an operation inside an interface
With Model Interface
1 Object operationType = Model.getMetaTypes().getOperation();
2 Object myOperation = Model.getUmlFactory.buildNode(elementType, myInterface);
The big drawback is that when a new model implementation is introduced that will introduce new model element types and the ?MetaTypes interface will continually need to adapt to provide a new getSomething() operation.
With Repository API
1 MetaType operationType = repository.getMetaType("Operation");
2 Element myOperation = operationType.createElement(myInterface);
A ?MetaType is requested from the Repository by a string identifier. That ?MetaType has the functionality to create instances.
One criticism of this technique is compile time safety. To help with this it would be possible to create a utility class with all the model element types already defined. This would be external to the repository API though. The example below uses a utility class called Type that has all the element types predefined as constants.
1 Element myOperation = Type.OPERATION.createElement(myInterface);
In reality however there will be limited places where such code will exist (reverse engineering is the main candidate). For this utility methods can be created or a ?RepositoryFacade built.
Most places would more likely be data driven
1 Element myElement = myMetatype.createElement(container);
Add an existing element to another
With Model Interface
Separate methods have been provided for each model element type. Once again this API will have to adapt when new model element are introduced.
1 Model.getCoreHelper().addOwnedElement(myNamespace, myInterface);
2 Model.getCoreHelper().addFeature(myOperation, myInterface);
3 Model.getCoreHelper().addParameter(myParameter, myOperation);
With Repository API
1 myNamespace.add(myInterface);
2 myInterface.add(myOperation);
3 myOperation.add(myParameter);
Recognising Element Type
With Model Interface
Separate methods have been provided for each model element type. Once again this API will have to adapt when new model element are introduced.
1 Model.getFacade().isANamespace(myElement);
2 Model.getFacade().isAFeature(myElement);
3 Model.getFacade().isAParameter(myElement);
With Repository API there is only one method to ever be aware of
1 myElement.instanceOf(Type.NAMESPACE);
2 myElement.instanceOf(Type.FEATURE));
3 myElement.instanceOf(Type.PARAMETER);