Just a reminder the buildNode and buildConnection are available on UmlFactory.
All the diagram buttons for creating model elements use buildNode and
buildConnection as do the popup menus on the explorer create element
menus.
There is no need to have a createXxxx method for every model element type.
Tom has pointed out in the past that the create methods are more
developer friendly
Model.getFactory().createClass()
compared to
Model.getFactory().buildNode(Model.getMetaType().getClass())
However at many times we have a class value of the model element type
we want and we're saving code by
if (metaType.equals(Model.getMetaType().getClass()) {
modelElement = Model.getFactory().createClass();
} else if (metaType.equals(Model.getMetaType().getInterface()) {
modelElement = Model.getFactory().createInterface();
}
compared to
modelElement = Model.getFactory().buildNode(metaType)
I would suggest only creating the createXxxxx methods if there is seen
as real added value to the developer.
I think we should be supporting both UML1.4 and UML 2.x for some time.
If there are problems with lots of if statements then we have some
problem in design patterns being used. Let people know of examples and
a few different eyes can take a look and offer some advice.
As for reinventing the way we separate the model implementations I
would support that. I've long discussed the wish for individual
wrappers around model elements that will tell us what functionality it
has rather than just Objects. I think when the model interface was
first invented it was seen as a stop gap and would be removed once we
had gone from NSUML to MDR. Hence the shortcuts that were taken at
that time.
I think more thought into this needs to come once we have UML2.x
support for all our current diagrams, prop panel and explorer.
Regards
Bob
2009/5/29 Luis Sergio Oliveira <[email protected]>:
> Tom Morris wrote:
>> (...)
>> Some other things that need changing (but aren't worth the cost):
>>
>> - make the API more object oriented. The current "every element
>> handle is just an Object" style is a hack
>> - make the API more granular. Having huge interfaces like Facade is crazy.
>> - make the API definition interface only with no required concrete classes
>>
> Hi Tom,
>
> As mainly from the API user side, I would like to say that Facade is
> easier to use than some XxxxHelper and XxxxFactory. This means - when I
> was learning my way on ArgoUML I understood more quickly how to use
> Facade than the other interfaces.
>
> That said I don't know how much is the cost/effort for the maintainer of
> the API...
>
> Regards,
>
> Luís
>
> ------------------------------------------------------
> http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2356668
>
> To unsubscribe from this discussion, e-mail:
> [[email protected]].
> To be allowed to post to the list contact the mailing list moderator, email:
> [[email protected]]
>
------------------------------------------------------
http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2356683
To unsubscribe from this discussion, e-mail:
[[email protected]].
To be allowed to post to the list contact the mailing list moderator, email:
[[email protected]]
