[Javalist] nyomják krahácsot (romlik a jáva)

[Tamás Viktor]

Ok, el tudok képzelni olyan helyzetet ahol van helye a setterben
valami odadrótozott validációnak, vagy plusz logikának. Ez az 5
forintos validáció szerintem nem az.
De ezt a logikát bele lehet tenni az értékadás alakú setterbe is.
...ami a zárójelek hiánya miatt valóban nem látszik hogy
függvényhívás, sőt ami rosszabb, hogy ugyanaz a literál gettert és
settert is jelenthet, attól függően hogy hol szerepel egy
kifejezésben.

Igazából csak a felpimpelt setter-ek miatt szóltam (be), mert ahol
ilyennel találkoztam -enkapszuláció ide vagy oda- ott mindig adódott
valami gebasz. (van amikor mégsem kell meghívni a plusz logikát mert
drága, szerializált adatok nem a szetteren keresztül állítódnak, rideg
lesz az osztály a plusz logika miatt - nem lehet másra használni -
öröklődést kell bevezetni - bonyolódik, ...)
V

2012/5/27 Peter Verhas <peter at verhas.com>:
> Nem vagyok benne biztos. Ezert lehet a validacio egy kulon metodusban, amit
> a setter meghivhat.
>
> Nem vagyok biztos benne, hogy leellenoriztes ezert a setterrel
> leellenoriztetem, mert az osztaly felelossege, hogy jol műkodjon
> (egysegbezaras?).
>
> On Sunday, May 27, 2012, Tamás Viktor wrote:
>>
>> Van az a logika, ami leellenőrzi az öttel osztást és csinál valamit,
>> ha fennáll a feltétel.
>> -Biztos vagy benne, hogy ez a logika csak ott, azon az egy helyen lesz
>> hasznos, abban az egy setterben? Nem lesz újra felhasználva sehol?
>> -Biztos vagy benne, hogy amikor meg akarják hívni a setter-t, nem
>> ellenőrizték már ezt le? Pl. amikor adatbázisból olvasnak vissza
>> előzőleg lementett adatokat.
>> -Biztos hogy oda kell az?
>> Azt a tendenciát látom, hogy egyre inkább kikerülnek a logikák a
>> setter-ekből. Ha mégis ott vannak, az bűzlik.
>> V
>>
>> 2012/5/26 Peter Verhas <peter at verhas.com>:
>> > Akkor minek lenne a setter? Éppen az a lényege, hogy leellenőrzi, hogy
>> > csak
>> > olyan érték kerülhessen be egy field-be, ami nem rontja el az objektum
>> > állapotát, az továbbra is megfelel az üzleti logikának.
>> >
>> > Szerintem nem érdemes ilyen sommás és lekezelő válaszokat írni, még némi
>> > gondolkodás után sem.
>> >
>> >
>> > On Saturday, May 26, 2012, Kristof Jozsa wrote:
>> >>
>> >> príma, az viszont helyesen egy business method, nem egy setter, ezzel
>> >> pedig a rövid történet végére is értünk.
>> >>
>> >> K
>> >>
>> >> 2012/5/26 Peter Verhas <peter at verhas.com>:
>> >> > Ne ragadjatok le a null-nál. Az csak egy pelda volt. Akkor inkabb a
>> >> > példámban az ellenőrzés legyen arra, hogy ha a számla típusa
>> >> > készpénzes,
>> >> > akkor a fizetendő összeg legyen öttel osztható.
>> >> >
>> >> >
>> >> > On Saturday, May 26, 2012, Zsombor wrote:
>> >> >>
>> >> >> Gondolom arra utal, hogy az általa tisztességesnek tekintett
>> >> >> nyelvekben
>> >> >> van külön típus az olyan változóra, ami sosem nulla, és ami lehet
>> >> >> nulla.
>> >> >> Persze itt nem kellene megállni, és lehet hiányolni a 23 karakter
>> >> >> hosszú
>> >> >> sztringek tipusát, és a páros számok tipusát, vagy egy bizonyos
>> >> >> regexp-re
>> >> >> matchelő stringek tipusát :)
>> >> >>
>> >> >> Zs
>> >> >>
>> >> >> 2012/5/26 Gábor Garami <gabor.garami at hron.me>
>> >> >>>
>> >> >>> Elvben barmilyen, non-primitive tipusu valtozo lehet null, igy nem
>> >> >>> ertem
>> >> >>> mit ertesz tipusos kerdes alatt.
>> >> >>>
>> >> >>> Garami Gábor
>> >> >>> gabor.garami at hron.me
>> >> >>> Skype: hron84
>> >> >>> Tel: +36 20 235 9621
>> >> >>>
>> >> >>> Sent from my T-Mobile G2
>> >> >>> Ezt a levelet telefonról adták fel, ékezethibákat tartalmazhat.
>> >> >>>
>> >> >>> 2012.05.25. 23:21, "Kristof Jozsa" <kristof.jozsa at gmail.com> ezt
>> >> >>> írta:
>> >> >>>
>> >> >>>> ezt nem vettem meg :) az egyetlen helyes válasz erre az h mert a
>> >> >>>> JavaBean szabvány ezt mondja, felesleges szerintem további
>> >> >>>> észérveket
>> >> >>>> keresni mögé. amúgy egy tisztességes nyelvben az hogy valami null
>> >> >>>> lehet-e az típusos kérdés és semmi köze a field beállításához.
>> >> >>>>
>> >> >>>> K
>> >> >>>>
>> >> >>>> 2012/5/24 Peter Verhas <peter at verhas.com>:
>> >> >>>> > 2012/5/24 Kristof Jozsa <kristof.jozsa at gmail.com>:
>> >> >>>> >> pontosan mitől lesz tisztább vagy olvashatóbb a kód ha minden
>> >> >>>> >> fieldhez
>> >> >>>> >> van egy getter és egy setter?
>> >> >>>> >>
>> >> >>>> >
>> >> >>>> > Mert ha azt használod, hogy
>> >> >>>> >
>> >> >>>> > invoice.setItems(invoiceItems);
>> >> >>>> >
>> >> >>>> > akkor sokkal kevesebb munkád lesz, amikor az Invoice osztályban
>> >> >>>> > például ellenőrizni akarod, hogy ne legyen null, vagy nulla
>> >> >>>> > elemű
>> >> >>>> > az
>> >> >>>> > invoiceItems, vagy azt, hogy minden tételre ki van-e töltve az
>> >> >>>> > ÁFA
>> >> >>>> > értéke. Ha
>> >> >>>> >
>> >> >>>> > invoice.items = invoiceItems;
>> >> >>>> >
>> >> >>>> > szerepel a kódban, akkor ezt  jelenleg Java-ban refaktorálnod
>> >> >>>> > kell,
>> >> >>>> > amikor az items mezőt priváttá teszed és elkészíted a settert és
>> >> >>>> > a
>> >> >>>> > gettert.
>> >> >>>> >
>> >> >>>> > Ha JavaX-ben (X > 7) az 'invoice.items = invoiceItems;' kód
>> >> >>>> > darab
>> >> >>>> > egy
>> >> >>>> > setter hívássá fordul le, az viszont felveti azt a kérdést, hogy
>> >> >>>> > a
>> >> >>>> > programozási nyelvben tényleg minden az-e, aminek látszik. A
>> >> >>>> > válasz
>> >> >>>> > pedig nem, mert ez értékadásnak látszik, miközben metódus hívás.
>> >> >>>> > Most
>> >> >>>> > még, Java-ban persze nem, és én nem is szeretném, hogy az
>> >> >>>> > legyen.
>> >> >>>> >
>> >> >>>> > Perl-ben olyan jópofa, hogy vannak ilyen automagic megoldások,
>> >> >>>> > de a
>> >> >>>> > Java nem Perl.
>> >> >>>> > 2005 októberben a Perl konferencián tartottam egy előadást, az
>> >> >>>> > volt
>> >> >>>> > a
>> >> >>>> > címe, hogy "Tiltsák be a Perl-t", és csak Java-ban szabad
>> >> >>>> > programozni.
>> >> >>>> > Sajnos nincs már meg a videó felvétel Ott volt Larry Wahl is. És
>> >> >>>> > mindenki végig azt hitte, hogy viccelek.
>> >> >>>> > _______________________________________________
>> >> >>>> > Javalist mailing list
>> >> >>>> > Javalist at lists.javaforum.hu
>> >> >>>> > http://lists.javaforum.hu/mailman/listinfo/javalist
>> >> >>>> _______________________________________________
>> >> >>>> Javalist mailing list
>> >> >>>> Javalist at lists.javaforum.hu
>> >> >>>> http://lists.javaforum.hu/mailman/listinfo/javalist
>> >> >>>
>> >> >>>
>> >> >>> _______________________________________________
>> >> >>> Javalist mailing list
>> >> >>> Javalist at lists.javaforum.hu
>> >> >>> http://lists.javaforum.hu/mailman/listinfo/javalist
>> >> >>>
>> >> >>
>> >> >
>> >> >
>> >> > --
>> >> > Verhás Péter
>> >> > ügyvezető
>> >> > Verhás & Verhás Szoftver Manufaktúra Kft.
>> >> > peter at verhas.com
>> >> > t: +36(30)9306805
>> >> > skype: verhas
>> >> >
>> >> > _______________________________________________
>> >> > Javalist mailing list
>> >> > Javalist at lists.javaforum.hu
>> >> > http://lists.javaforum.hu/mailman/listinfo/javalist
>> >> >
>> >> _______________________________________________
>> >> Javalist mailing list
>> >> Javalist at lists.javaforum.hu
>> >> http://lists.javaforum.hu/mailman/listinfo/javalist
>> >
>> >
>> >
>> > --
>> > Verhás Péter
>> > ügyvezető
>> > Verhás & Verhás Szoftver Manufaktúra Kft.
>> > peter at verhas.com
>> > t: +36(30)9306805
>> > skype: verhas
>> >
>> > _______________________________________________
>> > Javalist mailing list
>> > Javalist at lists.javaforum.hu
>> > http://lists.javaforum.hu/mailman/listinfo/javalist
>> >
>> _______________________________________________
>> Javalist mailing list
>> Javalist at lists.javaforum.hu
>> http://lists.javaforum.hu/mailman/listinfo/javalist
>
>
>
> --
> Verhás Péter
> ügyvezető
> Verhás & Verhás Szoftver Manufaktúra Kft.
> peter at verhas.com
> t: +36(30)9306805
> skype: verhas
>
> _______________________________________________
> Javalist mailing list
> Javalist at lists.javaforum.hu
> http://lists.javaforum.hu/mailman/listinfo/javalist
>