[Modelinterpreter] operacio parameterek multiplicitassal
Dévai Gergely
deva at caesar.elte.hu
Tue Jun 16 19:09:09 CEST 2015
Sziasztok!
Egy gyors meres alapjan egy elem atadasa, az uresseg vizsgalata es az elem lekerdezese ArrayList hasznalata eseten kb. 2-szer lassabb a sima referencianal.
Udv,
Gergo
On Tuesday, June 16, 2015 18:15 CEST, Dévai Gergely <deva at caesar.elte.hu> wrote:
Sziasztok!
A mult heti meetingen felmerult az a kerdes, hogy az operaciok mit csinalhatnak a paremeterkent kapott objektumhalmazzal.
Pl.: Egy [0..1] multiplicitasu in-out parametert kinullazhatnak-e? Vagy - forditva - egy null parameter helyebe adhatnak-e vissza egy objektumot? Altalaban: valtoztathatjak-e szabadon a szamossagot (a statikusan megadott korlatok kozott)?
A valasz az UML szabvany szerint igen.
http://www.omg.org/spec/UML/2.5/Beta2/PDF
108. oldal, "Parameters"
A parameterekhez UML-ben lehet "effect" property-t rendelni, ami egy tervezoi dontest fejez ki azzal kapcsolatban, hogy az adott behavior mit csinalhat az adott parameterrel: create, read, update, delete.
A szabalyok viszont furcsak:
- "Only in and inout Parameters may have a delete effect.": Azaz egy in parameterkent kapott objetum is torolheto!!!
- "Only out, inout, and return Parameters may have a create effect." (Ez logikus.)
Az adott parameterben kapott objektumhalmaz szamossaga tehat (a fenti szabalyok es a multiplicitas betartasa mellett) letrehozas es torles hatasara valtozhat.
Arra sajnos meg nem talaltam valaszt, hogy egy behavior kiszedhet-e egy objektumot a halmazbol anelkul, hogy torlne azt, vagy beletehet-e a halmazba mar korabban letezo objektumokat...
Mindenesetre ezek alapjan az implementacionkban [0..1] multiplicitas eseten sem johet szoba a sima objektumreferencia atadasa out es inout parameterek eseten (sem), mert elkepzelheto, hogy null megy be es nem null jon ki. Egyre inkabb hajlok arra, hogy minden parameteratadas egy (lehetoleg kis koltsegu) kollekcio segitsegevel valosuljon meg. Ez esetben nem kell wrapper osztalyokat csinalni a boolean, double, BigInt es String-hez.
De ha van valami konzisztens modon implementalhato optimalizacio, szoljatok!
Udv,
Gergo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://plc.inf.elte.hu/pipermail/modelinterpreter/attachments/20150616/d30ec2ab/attachment.html>
More information about the Modelinterpreter
mailing list