[Java lista] Class szintu tulajdonsag kenyszeritese compile-time

sashee gsashee at gmail.com
2009. Júl. 23., Cs, 10:48:28 CEST


Koszi a valaszokat mindenkinek!

Ugy latom, hogy out-of-the-box a java nem ad arra lehetoseget amit
gondoltam, es az AspectJ-t csak ezert overkillnek erzem. Kod
hozzaadasaval csalas megakadalyozasa nem szempont, mert ez szerver
oldali modell. Ugyanakkor az, hogy konfiguraciobol felulirhato legyen,
az valoban egy lenyeges pont, amelyre idovel biztosan figyelni kell.
Factory osztalyt is overkillnek erzem, mivel 1 osztaly helyett 2-t
kell irni(vagy 1-et irni, 1-et meg atirni)
Vegulis ugy dontottem, hogy marad az annotacios megoldas, de xml-bol
felul lesz irhato(ahogy J2EE-ben szokott lenni), es majd megprobalok
irni egy olyan ellenorzo progit, amely buildelesnel vegig megy az
osztalyokon, es megnezi, hogy nem hianyzik-e az annotacio valahonnan.

Megegyszer koszi mindenkinek!

sashee

2009/7/22  <istvan.ketler at lhsystems.com>:
> Szia,
>
> hát, ha nem akarod hogy a lények kívülről hozzáadhatók legyenek (api hozzáadásával új lényeket lehessen hozzáadni), akkor mégiscsak a factory-t javasolnám erre a célra. Nem lényenként egyet, hanem egyetlen "lénygyártó" factory-t. A "create" metódus első paramétere a létrehozandó lény osztálya. Az árakat tudhatja a factory, így az összes ár egy helyen van. A lények konstruktora package private, csak a factory tudja őket példányosítani.
>
> Ebben az esetben a csalás megvalósítása is egyszerű, mert egyetlen helyen kikerülöd az ellenőrzést, és máris minden lény létrehozható.
>
> Ha kívülről is meg akarod engedni, akkor pedig a módszer az, hogy minden lény osztály konstruktora private, és van neki egy statikus létrehozó metódusa, ami példányosítás előtt mindenfélét csinálhat. Például kötelező meghívnia az ősosztály egy statikus metódusát, ami megmondja, hogy van-e pénz a létrehozáshoz.
>
> A fenti két lehetőség mindegyike elég könnyen ellenőrizhető akár unit teszt segítségével is.
>
> Iván Ketler
>
> Lufthansa Systems Hungaria Kft.
> Airline Management Solutions
> Schedule & Revenue Management
> Alkotás u. 53.
> 1123 Budapest
> Hungary
>
> Tel: +36 1 887-2815
> Fax: +36 1 887-2977
>
> Room: MOM Park, Building A, Room 556
>
> e-mail: istvan.ketler at lhsystems.com
> Internet: www.LHsystems.hu
>
>
>
>
> Sitz der Gesellschaft / Corporate Headquarters: Lufthansa Systems Hungaria Kft, Budapest, Fövarosi Birosag 01-09-463417
> Geschaeftsfuehrung / Management Board: Monika Houck
>
> -----Original Message-----
>
> From: javalist-bounces at javagrund.hu [mailto:javalist-bounces at javagrund.hu] On Behalf Of sashee
> Sent: Wednesday, July 22, 2009 9:14 PM
> To: javalist at javagrund.hu
> Subject: Re: [Java lista] Class szintu tulajdonsag kenyszeritese compile-time
>
> Ketseg kivul ez a legegyszerubb megoldas, de az annotacios szerintem szebb(ugyanabban az osztalyban van a ra vonatkozo informacio). Dehat igen, ez sem kenyszerit semmit.
> Esetleg azt tudom meg elkepzelni, hogy a progi indulasnal leellenorzni az osszes leszarmazott osztalyt, hogy ott van-e az annotacio, es akkor legalabb rogton indulasnal kiderul ha lemaradt vhonnan.
>
> 2009/7/22 Böszörményi Péter <zmblevlist at gmail.com>:
>> Igen, igy mar erteheto.
>>
>> Mi lenne, ha lenne egy osszerendeles, ami csak azt mondana meg, hogy
>> melyik lenyhez milyen ar ertek tartozik. Pl. egy Class - double paros.
>> Ez ugyan a forditas ideju ellenorzest nem teszi lehetove, de nem lesz
>> nyakatekert a kod.
>>
>> On Wed, 22 Jul 2009 20:59:17 +0200, sashee <gsashee at gmail.com> wrote:
>>
>>> Ok, akkor reszletesebben:
>>>
>>> A jatekosoknak van penzuk, es vehetnek goblinokat. A goblinoknak van
>>> aruk, es ez a goblinra mint fajra jellemzo(tehat minden goblin
>>> ugyanannyiba kerul). A goblint csak akkor akarom peldanyositani, ha
>>> az tenyleg letre is jott. A goblinnak van egy absztrakt ose, hogy
>>> kesobb lehessen mas lenyeket is letrehozni.
>>> Venni varosban lehet, ezert a varosnak keszitettem egy olyan
>>> metodust, ami megkapja azt az osztalyt, amilyen lenyt szeretne venni a jatekos.
>>> Ebben a metodusban szeretnem megcsinalni azt, hogy eloszor
>>> leellenorzni az adott lenytipusnak az arat, megvizsgalja, hogy a
>>> jatekosnak mennyi penze van, es ha van elegendo, akkor letrehoz egy
>>> uj peldanyt az adott lenybol.
>>> Ezt szeretnem minel elegansabban es a leheto legkevesebb plusszal
>>> megirni, ezert gondoltam, hogy ha minden leny class-aban tarolom az
>>> arara vonatkozo adatot(pl annotacioban), akkor az igazabol 1 sor, es
>>> mukodik. Azonban ha irok egy uj lenyt, akkor semmi sem fogja
>>> kikenyszeriteni, hogy legyen neki az arra vonatkozo informacioja,
>>> csak futas kozben fog elszallni.
>>>
>>> Remelem igy erthetobb
>>>
>>> sashee
>>>
>>> 2009/7/22 Böszörményi Péter <zmblevlist at gmail.com>:
>>>> Olvastam az elso levelet (goblin + getAr), de tudnad meg egy kicsit
>>>> reszletezni a dolgot? Ugy erzem itt a koncepcioban van hiba.
>>>>
>>>> On Wed, 22 Jul 2009 20:33:36 +0200, sashee <gsashee at gmail.com> wrote:
>>>>
>>>>> Absztrakt fuggveny meghivasahoz peldanyositani kell az osztalyt.
>>>>> Nekem akkor kellene meghivni a fv-t mielott peldanyositom.
>>>>>
>>>>> 2009/7/22 Böszörményi Péter <zmblevlist at gmail.com>:
>>>>>> On Wed, 22 Jul 2009 20:26:59 +0200, Tamás Sallai
>>>>>> <gsashee at gmail.com>
>>>>>> wrote:
>>>>>>> erzem. Inkabb olyasmi lenne a legjobb, ha lenne mondjuk
>>>>>>> @MustOverwrite metaannotacio, amit minden gyerekosztalyban felul
>>>>>>> kell irni. De sajnos meg nem talaltam ilyet.
>>>>>>
>>>>>> Pedig letezik. Absztrakt fuggvenynek hivjak.
>>>>>>
>>>>>>>
>>>>>>> sashee
>>>>>>>
>>>>>>> 2009/7/22 Kristof Jozsa <kristof.jozsa at gmail.com>:
>>>>>>>> az eredeti kérdésre aspectj, compile-time policy enforcement,
>>>>>>>> pár sor.
>>>>>>>> tankönyvi példa:
>>>>>>>>
>>>>>>>> static aspect FlagNonFactoryCreation {
>>>>>>>>     declare error
>>>>>>>>     : call(Product.new(..)) && !within(ProductFactory+)
>>>>>>>>     : "Only ProductFactory can create Products"; }
>>>>>>>>
>>>>>>>> azt viszont nem látom h a játékos pénzét hogy látod compile-time
>>>>>>>> ill miért nem a goblin konstruktorába írod bele a feltételt, de
>>>>>>>> goblinokhoz nem értek..
>>>>>>>>
>>>>>>>> K
>>>>>>>>
>>>>>>>> 2009/7/22 sashee <gsashee at gmail.com>
>>>>>>>>>
>>>>>>>>> Sziasztok!
>>>>>>>>>
>>>>>>>>> Van arra valami mod javaban, hogy compile time legyen
>>>>>>>>> kenyszeritve classhoz tartozo tulajdonsag? Pl annotacio meglete
>>>>>>>>> vagy statikus metodus.
>>>>>>>>> Egy pelda a kerdeshez, igy szerintem konnyebben ertheto, hogy
>>>>>>>>> mit
>>>>>>>>> szeretnek:
>>>>>>>>> Van egy varos, benne lehet felvenni goblinokat. Goblinnak ara
>>>>>>>>> van, es csak akkor szeretnem peldanyositani, ha a jatekos
>>>>>>>>> tenyleg ki is tudja fizetni. Igy ha a karakterek ososztalyba
>>>>>>>>> teszek egy abstract int
>>>>>>>>> getAr() fv-t, akkor azt sajnos nem tudom meghivni, mivel amikor
>>>>>>>>> ezt ellenorizni szeretnem, akkor meg nincsen goblin peldanyom.
>>>>>>>>> Ezert jolenne egy olyan statikus metodus vagy annotacio,
>>>>>>>>> amelyik biztos, hogy letezik, igy reflectionnel mar meg lehetne
>>>>>>>>> nezni az arat barmelyik karakternek, es nem fordulhat az elo,
>>>>>>>>> hogy irok mondjuk egy orkot, es lefordul, de futas kozben pedig
>>>>>>>>> hibat dob.
>>>>>>>>> Talan a legjobb, amit eddig talaltam, az az Inherited
>>>>>>>>> metaannotacioval ellatni az absztrakt os egy annotaciojat,
>>>>>>>>> akkor legalabb mindig talal valamilyet, de igazabol en
>>>>>>>>> kenyszeriteni szeretnem a programozot, hogy ezt mindenkeppen
>>>>>>>>> felul kell biralnia.
>>>>>>>>> Ugy gondolom, hogy talan egy Factory-val lehetne megcsinalni
>>>>>>>>> jora, hogy lenne egy GoblinFactory, ami tudja az arat, valamint
>>>>>>>>> tud peldanyositani is, de en nem szeretnek mindig 2 osztalyt
>>>>>>>>> letrehozni, amikor igazabol 1 is eleg lenne.
>>>>>>>>>
>>>>>>>>> Tud esetleg erre vki vmi elegans megoldast?
>>>>>>>>>
>>>>>>>>> Koszi elore is
>>>>>>>>>
>>>>>>>>> sashee
>>>>>>>>> _______________________________________________
>>>>>>>>> Javalist mailing list
>>>>>>>>> Javalist at javagrund.hu
>>>>>>>>> http://javagrund.hu/mailman/listinfo/javalist
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Javalist mailing list
>>>>>>>> Javalist at javagrund.hu
>>>>>>>> http://javagrund.hu/mailman/listinfo/javalist
>>>>>>>>
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Javalist mailing list
>>>>>>> Javalist at javagrund.hu
>>>>>>> http://javagrund.hu/mailman/listinfo/javalist
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Üdvözlettel,
>>>>>> Böszörményi Péter
>>>>>> _______________________________________________
>>>>>> Javalist mailing list
>>>>>> Javalist at javagrund.hu
>>>>>> http://javagrund.hu/mailman/listinfo/javalist
>>>>>>
>>>>> _______________________________________________
>>>>> Javalist mailing list
>>>>> Javalist at javagrund.hu
>>>>> http://javagrund.hu/mailman/listinfo/javalist
>>>>
>>>>
>>>>
>>>> --
>>>> Üdvözlettel,
>>>> Böszörményi Péter
>>>> _______________________________________________
>>>> Javalist mailing list
>>>> Javalist at javagrund.hu
>>>> http://javagrund.hu/mailman/listinfo/javalist
>>>>
>>> _______________________________________________
>>> Javalist mailing list
>>> Javalist at javagrund.hu
>>> http://javagrund.hu/mailman/listinfo/javalist
>>
>>
>>
>> --
>> Üdvözlettel,
>> Böszörményi Péter
>> _______________________________________________
>> Javalist mailing list
>> Javalist at javagrund.hu
>> http://javagrund.hu/mailman/listinfo/javalist
>>
> _______________________________________________
> Javalist mailing list
> Javalist at javagrund.hu
> http://javagrund.hu/mailman/listinfo/javalist
> _______________________________________________
> Javalist mailing list
> Javalist at javagrund.hu
> http://javagrund.hu/mailman/listinfo/javalist
>


További információk a(z) Javalist levelezőlistáról