> MArtin Schumacher wrote:
>> Hallo all,
>>
>> these days I had a look to the MetaFacades of the BPM4Struts-Cartridge
>> and I was a little confused:
>>
>> There are a lot of Attributes at the MetaFacade-Classes, which are
>> generated into getter- and handleGet-Methods respectively. This concept
>> I do not understand. Why don't you modell "get<Name>"-Methods?
>>
>
> because it's easier to model attributes
> and because we use the same signatures to call them in VTL and OCL
>
> why do we need to model exactly what is generated ? we model the ideas
> we have in mind and let the cartridge take care of it
>
fyi: we used to model operations
another advantage of using attributes is that you can cache their values,
with an operation it's different (since it can take parameters)
>> My next point is the inheritance in the MetaFacades.
>>
>> If i got two MetaFacades
>> +------------+ +------------+
>> | A | | B |
>> +------------+<-----------+------------+
>> | doA():void | | doB():void |
>> +------------+ +------------+
>>
>> my generated source code will look this way:
>> ------- Code B.java -----------------------------------
>> public class B {
>> private A a;
>> (...)
>> public void doA() {
>> a.doA();
>> }
>> }
>> -------------------------------------------------------
>>
>> But why is it implemented this way? If I have this I cannot use all the
>> fine stuff of inheritance:
>> - overriding of methods
>> - inheritance of more than one level (a new Metafacade C inherits from B
>> cannot use doA())
>>
>
> we need multiple inheritance, and this does not exist in Java (except
> for interfaces, as JMI is doing)
>
a metafacade still 'inherits' the parent's features, for overriding you
simply override the getXXX method instead of the handleGetXXX method
about the inheritance of more than one level: we use multi-level facade
'inheritance' and calling those ancestor features works fine
what's going wrong ? any specifc error ?
>> My last point:
>>
>> Why are the methods generated with the prefix "handle"? Thats not what I
>> modeled...
>>
>
> they are the callbacks generated in the xxxImpl classes, it decouples
> your implementation from the generated signatures
>
>> MArtin
>>
>>
>
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click
_______________________________________________
Andromda-devel mailing list
Andromda-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/andromda-devel
